There was never any reply to this message (below) I sent a few months ago
about a problem with the method used by the Digestor for class loading.
In a number of places, it uses the old style
class.forName(name);
instead of the proper
Thread.getCurrentThread.getContextClassLoader.loadClass(name);
The second form is _much_ preferred to the first, because the first will
potentially fail in any situation where there are multiple classloaders (one
owning the other), and the Digester is used in code loaded by both
classloaders (please see my original message for more details).
This kind of situation is very common any time you have something like a
server (web, etc.) with containers in it, each container having its own
classloader associated with it in order to handle code visibility and
versioning. Using the digester in this situation is not possible without
modifying the code to use the second form.
I am quite willing and able to upload patches to 4 digester files to fix
this, assuming they will be checked in by somebody. The only implication is
that the code will no longer run under JDK 1.1, but Struts already needs 1.2
in any case...
For more details on classloading issues in Java, here are a couple of
excellent white papers:
Understanclind Class.forName();
http://www.develop.com/downloads/DynLoad.zip
Exploiting the Java Virtual Machine:
http://www.develop.com/downloads/DevWPJav.pdf
> -----Original Message-----
> From: Colin Sampaleanu [mailto:[EMAIL PROTECTED]]
> Sent: February 22, 2001 10:06 PM
> To: '[EMAIL PROTECTED]'
> Subject: ClassLoader used in Digester
>
>
> We are currently using the digester in a server we build that
> uses custom
> classloaders for some containers within it, which load custom apps.
>
> We use the Digester in the server itself, and some of the
> apps being loaded
> in the containers also want to use the Digester. The problem
> is that when an
> app creates a Digester instance, it is created by the parent (system)
> classloader that loaded the server, since the server had
> already used the
> Digester and that classloader knows about it. When the
> Digester then does a
> Class.forName in one of its rules to create an object, it
> knows nothing
> about the container's ClassLoader and the classes within it.
> The class is
> only withing the app, and so can't be found.
>
> Is there any downside to changing the Digester to always use:
> Thread.getCurrentThread.getContextClassLoader.loadClass(name);
> instead of
> class.forName(name);
>
> The code would no longer work in JDK 1.1, but that is already
> the case...
>
