Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Date: Tue, 26 Sep 2000 12:08:39 -0400 (EDT)
From: Aaron Mulder <ammulder@alumni.princeton.edu>
To: tomcat-dev@jakarta.apache.org
cc: cocoon-dev@xml.apache.org
Subject: Re: re loading of classes in tomcat 3.2b4 is _sloooooow_@6
In-Reply-To: <39CFF2AA.8D474DD7@eng.sun.com>
Message-ID: <Pine.LNX.4.21.0009261205320.28655-100000@gentoo.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 25 Sep 2000, Craig R. McClanahan wrote:
> The third advantage is that some libraries will not work correctly unless they
> are installed in the webapp.  I believe Cocoon has run into this -- I'll
> describe what I ran into with Struts because it's similar.
> 
> Struts includes a module called Digester (very similar to the XmlMapper that is
> used inside Tomcat to configure itself from the server.xml and web.xml files).
> One of the things you can do is create a new object when a particular XML
> element is encountered.  But, if the digester classes are loaded from the
> system class path, and the Java class of the object you're trying to create is
> in the webapp (a very typical case), you're out of luck --
> ClassNotFoundException because the Digester tries to use the classloader it was
> itself loaded from (i.e. system class loader).

	This can be solved by judicious use of the
Thread.contextClassLoader under 1.2.  Of course, the library has to
support that, but Tomcat should already: under 3.2 at least there's the
Jdk12Interceptor that would set the contextClassLoader for all calls - I
assume 4.0 has something similar.

Aaron