overriding container-wide libray JARs?

[Ingo Luetkebohle <in...@t17.fargonauten.de>]

Hiya,

I need to override a container-wide library, i.e. use only the class
files provided with my servlet even though Tomcat provides (and
pre-loads, its the Jaxp parser) classes of the same name.

The servlet spec 2.3 PFD says in section 9.6.2 that containers should
provide some method for servlets to require extensions from a specific
vendor (i.e. ASF, instead of sun), supposedly through the
MANIFEST.MF. I couldn't find any details for that, though. I'm using
TOMCAT 4.0m4

Has Tomcat support for doing this?

Regards

-- 
	Ingo Luetkebohle / ingo@blank.pages.de / 95428014

its easy to stop using Perl: I do it after every project

Re: overriding container-wide libray JARs?

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Ingo Luetkebohle wrote:

> On Fri, Nov 10, 2000 at 08:57:57AM -0800, Craig R. McClanahan wrote:
> > Thus, if a class "com.mycompany.mypackage.Foo" is visible in both a JAR
> > file in your webapp and in the shared extensions area, it will be loaded
> > from your webapp.  This is different from the behavior of Tomcat 3.2,
> > which puts (1) and (2) at the end of the list rather than the front.
>
> Ah, ok... I had previously gotten the impression that Tomcat 3.x also
> used that ordering and was confused (btw, the classloader.html is an
> excellent piece of information, too bad it only covers 4.0!) Just to
> make this dead sure, though:
>
> If I have Xerces in my WEB-INF/lib and don't modify anything about the
> default Tomcat 4.0m4 install, then:
>         1) my servlets will use Xerces
>         2) JSP's within my webapp will use JAXP because they
>            are handled by jasper
>

Umm, in theory you are correct.

The Jasper servlet itself (org.apache.jasper.servlet.JspServlet), because it
is in the shared extensions directory ($CATALINA_HOME/lib), is loaded by the
shared extensions classloader, rather than the webapp one -- and therefore,
any classes that the JSP servlet itself loads will start from there and go up
(thus finding the JAXP-compliant parser that is in $CATALINA_HOME/lib).

However, the JSP servlet needs to explicitly use the webapp class loader (so
it can find things like bean classes that are in WEB-INF/classes or
WEB-INF/lib).  I'm not sure where it looks to load the parser classes --
Pierre Delisle can better answer that when he returns on Monday.

I've seen some reports of "package sealing violations" recently -- I believe
these are due to references to a Java package initially loaded in the webapp
class loader, but where some classes with that same package name are in the
shared extensions area.  Because of the emergency focus on Tomcat 3.2 this
week (finally -- almost done with it :-) I haven't been able to thoroughly
investigate this yet, but I've seen Xerces do this kind of thing beore, and
cause conflicts with a parser that's on the "class path" higher up the
hierarchy.

The goal has been that Jasper can use any JAXP-1.1 compliant parser.  At this
point in time, I don't believe that Xerces has implemented all of that (we
needed the SAX2 support through the standard API), but it should not be
difficult -- and as soon as it does you'll be able to replace the parser
Jasper is using with Xerces (in $CATALINA_HOME/lib) and not have any
conflicts.

>
> Is that correct?
>
> Regards
>
> --
>         Ingo Luetkebohle / ingo@blank.pages.de / 95428014
> --
> PraxisXML Open Source contact; Computational Linguistics
> student; Fargonauten.DE sysadmin; Gimp Registry (not-)maintainer;
> --
> its easy to stop using Perl: I do it after every project

Craig

Re: overriding container-wide libray JARs?

[Ingo Luetkebohle <in...@blank.pages.de>]

On Fri, Nov 10, 2000 at 08:57:57AM -0800, Craig R. McClanahan wrote:
> Thus, if a class "com.mycompany.mypackage.Foo" is visible in both a JAR
> file in your webapp and in the shared extensions area, it will be loaded
> from your webapp.  This is different from the behavior of Tomcat 3.2,
> which puts (1) and (2) at the end of the list rather than the front.

Ah, ok... I had previously gotten the impression that Tomcat 3.x also
used that ordering and was confused (btw, the classloader.html is an
excellent piece of information, too bad it only covers 4.0!) Just to
make this dead sure, though:

If I have Xerces in my WEB-INF/lib and don't modify anything about the
default Tomcat 4.0m4 install, then:
	1) my servlets will use Xerces
	2) JSP's within my webapp will use JAXP because they
	   are handled by jasper

Is that correct?

Regards

-- 
	Ingo Luetkebohle / ingo@blank.pages.de / 95428014
--
PraxisXML Open Source contact; Computational Linguistics
student; Fargonauten.DE sysadmin; Gimp Registry (not-)maintainer;
--
its easy to stop using Perl: I do it after every project

Re: overriding container-wide libray JARs?

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Ingo Luetkebohle wrote:

> Hiya,
>
> I need to override a container-wide library, i.e. use only the class
> files provided with my servlet even though Tomcat provides (and
> pre-loads, its the Jaxp parser) classes of the same name.
>
> The servlet spec 2.3 PFD says in section 9.6.2 that containers should
> provide some method for servlets to require extensions from a specific
> vendor (i.e. ASF, instead of sun), supposedly through the
> MANIFEST.MF. I couldn't find any details for that, though. I'm using
> TOMCAT 4.0m4
>
> Has Tomcat support for doing this?
>

Tomcat 4.0 supports the "optional versioning specification" mechanism (the
servlet spec points you at a doc in the JDK 1.3 docs that describe this),
but that mechanism is primarily designed to allow your web app to declare
its dependence on external libraries -- Tomcat will refuse to load the app
if one of the packages you declare dependence on is not available.

However, for general use, Tomcat 4.0 does allow a webapp to "override"
system classes, because its webapp class loader follows this ordering:
(1) WEB-INF/classes
(2) WEB-INF/lib/*.jar
(3) Shared extensions (in $CATALINA_HOME/lib)
(4) System classpath (preconfigured in the startup script --
     note that any CLASSPATH environment variable is
     totally ignored
(5) Bootstrap and Java base classes

Thus, if a class "com.mycompany.mypackage.Foo" is visible in both a JAR
file in your webapp and in the shared extensions area, it will be loaded
from your webapp.  This is different from the behavior of Tomcat 3.2,
which puts (1) and (2) at the end of the list rather than the front.

>
> Regards
>

Craig McClanahan