tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: Tomcat 4.0.4b1 calls init() twice? (and strange bugs)
Date Mon, 11 Mar 2002 17:15:43 GMT

On 11 Mar 2002, Kevin A. Burton wrote:

> Date: 11 Mar 2002 01:42:39 -0800
> From: Kevin A. Burton <>
> Reply-To: Tomcat Developers List <>
> To: Tomcat Developers List <>
> Subject: Re: Tomcat 4.0.4b1 calls init() twice? (and strange bugs)
> Hash: SHA1
> "Remy Maucherat" <> writes:
> <snip/>
> > > I can't move my code from WEB-INF/classes because I am using Tomcat class
> > > reloading to test out new extension code when I am developing...
> > >
> > > Puts us in a tough situation huh ;)
> >
> > With JDK 1.4, it gets really tricky then, since no matter what the
> > webapp CL has to delegate loading Xalan to the sys CL (ok, it didn't
> > in 4.0.1, but that was a bug). The only way out would be for Xalan to
> > use the context classloader
> What is the context classloader?  I didn't see that:

That's because it's a standard J2SE feature:

  ClassLoader contextClassLoader =

In a servlet 2.3 environment, this is required to be the webapp class
loader (for the current request processing thread).  Although not required
by servlet 2.2, it's very commonly implemented that way (including by
Tomcat 3.2 and 3.3).

The point of this is to let you put something like Xalan in the shared
library directory (which is therefore loaded by a separate class loader),
but still give it access to the webapp class loader.  However, the shared
library code must deliberately choose to access it, instead of just using
Class.forName() to dynamically load classes -- something like this:

  private Class loadApplicationClass(String appClassName) throws Exception {
      ClassLoader appClassLoader =
      if (appClassLoader == null) {
          appClassLoader = this.getClass().getClassLoader();
      return (appClassLoader.loadClass(appClassName));

so Xalan would have to do this explicitly to play nice when put into the
shared class loader of Tomcat (or any other container that implements the
concept of shared JAR files in a parent class loader).

> > to load its extensions.
> I have to be honest... I think this is a HUGE problem.
> I haven't been following these issues on tomcat-dev.  Are there any threads I
> should read?
> I think that this will cause a LOT of people a LOT of headaches.  The
> Cocoon2 guys should really feel this.  So would anyone doing
> Xerces/Xalan stuff from within a Servlet.
> What happens under 1.4 which makes this different?  Is there anything that can
> be done about this?

What happens is that JAXP/1.1 is built in to JDK 1.4 -- therefore, once
you have delegated up to the shared class loader, it will delegate up all
the way to the version included in the JDK.

> Anyway... whatever the long term solution to this, I think it needs to be
> documented very well....

In the HEAD branch of Tomcat 4, we dealt with this by introducing a new
"common/endorsed" directory, and modified the Tomcat startup script to use
the new JDK 1.4 "java.endorsed.dirs" system property.  For examle, this
lets run Xerces 2 or Xalan 2 even on a 1.4 system, by putting them into
the common/endorsed directory.  It still works transparently on a JDK 1.3
system, which ignored java.endorsed.dirs, because we build common/endorsed
in to the common class loader.

More info about java.endorsed.dirs is at:

Porting this back to 4.0.x would seem like a low risk way to deal with the
issue -- it seems to work pretty well.

> Anyway... sorry to be freaking out about this.  We have a fairly
> distributed app ( and it uses Tomcat
> 4.x.... I can't release on 4.0.1 because of security issues and I can't
> use any of the other builds because it breaks my code... :(
> Thanks for you help Remy!  Time for sleep...
> Kevin


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message