On Tue, 1 May 2001, Scott Sanders wrote:
> I can apply the patch to the code in jakarta-commons-sandbox as well.
>
> I would assume that a dependency on JDK 1.2 is not a problem. Someone
> will speak up if it is not.
>
No, it's not a problem. Struts requires 1.2 or later.
> Scott
>
Cragi
> Colin Sampaleanu wrote:
>
> > 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...
> >>
>
>
>
