See intermixed.
On Sat, 10 Mar 2001, David Wall wrote:
> > The same class loader is used to load all classes within a particular web
> > application, but there is more to the story than that. See below.
>
> This is true for both JSP pages and for servlets, including those servlets
> loaded at startup?
>
Yes. Everything loaded for a particular web application is loaded by the
web app class loader, either directly or indirectly (via delegation to a
parent).
>
> > There is actually a hierarchy of class loaders created when Tomcat is
> > running:
> > - Bootstrap class loader (Java system classes)
> > - Extensions class loader (JAR files from $JAVA_HOME/jre/lib/ext)
> > - System class loader (contents of CLASSPATH at startup time)
> > - Webapp class loader (contents of WEB-INF/classes and WEB-INF/lib
> > for your particular web application)
>
> Sure, this is as I'd expected. And since a Tomcat can run multiple webapps,
> presumably it has multiple classloaders, one for each, correct?
>
Yes, one webapp class loader per webapp. This is true for pretty much
every servlet container.
The discussion above covered Tomcat 3.2. In the Tomcat 4.0 source
repository, there's a document describing how Tomcat 4.0 is set up
(catalina/docs/dev/classloaders.html). It's quite a lot more complicated,
but at root the same principles apply. You might find this document
instructive, however.
> > * Do not rely on system extensions in $JAVA_HOME/jre/lib/ext. If you
> > do, those classes are *not* allowed to reference any classes on the
> > system class path, or inside your web application.
>
> This is empty on my system.
>
> > * Do not rely on adding classes onto your CLASSPATH (or putting them in
> > $TOMCAT_HOME/lib) before starting Tomcat. Such classes will have
> > problems with downward references, as described above. Also, support
> > for shared library classes is ***not*** required by the servlet spec,
> > so you cannot count on this facility in a portable app.
>
> What is a "shared library class"? In my case, the problem is with classes
> that are dynamically loaded, such as a JCE crypto provider or JDBC provider.
> Or are you referencing JNI stuff or something else?
>
I'm using kind of a circular definition here -- a "shared library
class" is a class that you want made visible to multiple web apps, if your
servlet container provides such a technique. For Tomcat 3.2, that covers
anything you put on the system CLASSPATH at startup time, which includes
any JAR files in $TOMCAT_HOME/lib.
> > * Put all classes your application needs into WEB-INF/classes, or
> > in JAR files unde WEB-INF/lib. In this way, they will all be loaded
> > by the same class loader and not have any referencing problems.
>
> This is what I do, but I get the class not found exception. When I DO put
> them in the CLASSPATH just before starting Tomcat, then they are found.
> This is the exact opposite of what you suggest, and of course what you
> suggest is what I want to happen <smile>.
>
> Is there something I can do at the point in my code where I am trying to
> load the JCE provider and I get an error to help see what's wrong? I know
> the class exists in a jar file in the WEB-INF/lib...
>
> > There are other specific issues with specific libraries, and there are
> > some changes in how class loading works in Tomcat 4.0, but the above
> > outline identifies what to do about the majority of class loading issues
> > in servlet containers.
>
> Do you think Tomcat 4.0 reliable enough now to use instead of 3.2.1?
>
I do, but I'm biased :-). Actually, it's kind of fun to watch the 3.3
folks busily fixing bugs (either inherited from 3.2 or caused by the
refactoring work in 3.3) that don't exist in 4.0.
> David
>
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
