cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: ClassLoading and Cocoon 2
Date Wed, 14 Feb 2001 17:43:45 GMT
Stefano Mazzocchi wrote:

> [brought Craig into the discussion since he's the classloading guru
> around here]
> Berin Loritsch wrote:
> >
> > Does anyone know how to selectively load classes from a parent ClassLoader?
> >
> > I recently made Cocoon live inside it's own ClassLoader.  This is a good thing
> > as it protects us from a myriad of issues with IBM WebSphere and other Servlet
> > Containers that have wacky ClassLoaders.  However, the one thing it does not
> > protect us from is XML Parser conflicts.  If we can resolve against the Servlet
> > Engine's classes for things like javax.servlet.* and Enterprise applications,
> > but not anything else, then we are just about there.
> I don't understand what you mean by parser conflicts in this case: if
> Cocoon has its own classloader and delegates to the parent only when it
> doesn't find its classes (just like Catalina does) there is no conflict.
> What am I missing?

There is at least one conflict that can still exist -- if one of the packages you are
accessing is "sealed" (with an entry in the MANIFEST.MF file), you will still have
problems.  Unfortunately, this currently affects Tomcat 4.0 (and is the primary
reason we have not gone to beta 2 yet).  The JAXP-1.1ea2 parser (jaxp.jar and
crimson.jar) are required by Jasper, and are therefore placed in the lib directory.
This conflicts with the use of an XML parser loaded into WEB-INF/lib (such as

As far as I can tell :-(, there is no way to override a sealed JAR file, even using
the custom class loader override trick, without completely reimplementing
URLClassLoader as well.

Our short term approach to this will be to allow you to use Xerces (2.0) as the
shared XML parser instead of Crimson.  Longer term, we're going to make Jasper load
its XML parser from a separate class loader -- undoubtedly for the same kinds of
reasons that you guys are doing this with Cocoon.

To get back to the original question, it is feasible in a limited sense to load
classes selectively.  What this would require is following the
ClassLoader.getParent() chain up to the class loader containing the class you want
(and skipping the class loaders you do not want).  However, this requires pretty
intimate knowledge of how class loaders are arranged in a given container, and even
particular versions of a container.

> > One way is to explicitly handle the Parent ClassLoader separately from the
> > way the URLClassLoader handles it.  In other words, it always checks in the
> > current ClassLoader first (this does not seem to be happening), and then
> > it checks in the parent ClassLoader.
> Yeah, I thought Catalina used this approach, isn't it Craig?

Yes - we created a custom subclass of URLClassLoader
(org.apache.catalina.loader.StandardClassLoader) that by default looks in the local
repositories before delegating.

> > Another approach is to separate out the CocoonServlet classes from the main
> > Cocoon.jar and have all the specific Cocoon libraries in a non traditional
> > location--this may be easier to implement.
> >
> > Example:
> > --------
> >
> > WEB-INF/lib
> >          /avalon-api.jar
> >          /cocoon-servlet.jar
> >
> > WEB-INF/cocoon-lib
> >          /Xerces_1_2_3.jar
> >          /cocoon.jar
> > ....
> > And all the other libs
> >
> > The approach would require making an Interface that would be in
> > cocoon-servlet.jar that would allow us to send requests to the
> > propper Cocoon class.  It would also force us to include the
> > ClassLoader in there.
> >
> > This keeps Cocoon almost completely isolated, and enforces the
> > ClassLoader to be used.

One cautionary note - servlet containers that run under a security manager (such as
will now be possible with Catalina) may prevent you from creating your own class
loader.  In practice, this probably will not be an issue (nearly every JSP
implementation is going to have to use classloaders to implement the page recompile
stuff), but it is something to watch out for.

> Yuck. I vote for implementing a better classloader (even borrowing
> Catalina's code if possible).

Be my guest.  I worked *very* hard to make sure that there were no Catalina
dependencies in this code -- it only imports java.* stuff - so it should be easy to

> --
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                           able to give birth to a dancing star.
> <>                             Friedrich Nietzsche
> --------------------------------------------------------------------

View raw message