cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Haraburda <>
Subject Re: ClassLoader issues
Date Mon, 10 Jun 2002 19:26:28 GMT
On Mon, 2002-06-10 at 13:38, Sylvain Wallez wrote:
> After some investigation in CocoonServlet's classloading stuff (which 
> has a loooong history), it appears to me that classpath and classloader 
> are different issues and that we don't really need the 
> RepositoryClassloader there. Discussion follows...

I agree.  It looks like RepositoryClassLoader is needed to compile
things like XSPs and the sitemap and such, but this is internal to
Cocoon, so there isn't a problem there.  My arguments for having it
removed from CocoonServlet (besides the fact that it breaks JNDI in
Tomcat) are:

1 - J2SE API Docs (take a look at java.lang.Thread javadoc) imply that
it is a Thread's creator's responsibility to set the
ContextClassLoader.  Since the servlet engine (Tomcat in this case)
creates the Threads, it is responsible for this
2 - The J2EE spec (1.3) in section further elaborates on the
needs for a ContextClassLoader (that is set by the J2EE container)

(I know I've said these two things before -- just re-iterating :-)

> The classpath is used to instruct the Java compiler used for XSPs where 
> it should find the classes, since it (unfortunately) doesn't care about 
> the current classloader. So the extra-classpath parameter is IMO usefull 
> only when there are some classes visible from the webapp that are 
> neither in the system classpath, neither in the WEB-INF/lib or 
> WEB-INF/classes directory. This case may arise when some libraries 
> common to several webapp contexts are deployed in tomcat/lib (see 
> for a clear explanation of this).

And this behavior I believe, is Tomcat-specific.  Really, web
application developers should follow the spec guidelines and package
their web-app with all required librares and classes in WEB-INF/lib and
WEB-INF/classes -- I think the extra-classpath parameter could be
removed also.

> Now Cocoon relies heavily on dynamic loading of classes named in 
> cocoon.xconf and sitemap.xmap through Avalon, and to avoid classloading 
> problems when a class defined by a higher-lever classloader (such as 
> tomcat/lib) loads a class defined by a lower-level class loader (such as 
> WEB-INF/lib), all classloading is made using the current thread's 
> context classloader.

Yup.  That's basically why the ContextClassLoader exists.  The J2EE spec
says essentially the same thing.

> The purpose of setting the context classloader in CocoonServlet is to 
> ensure that the webapp classloader (i.e. the lowest level) will 
> effectively be used by Cocoon and Avalon. Now this could be limited to 
> CocoonServlet's classloader (i.e. the webapp classloader) and not it's 
> child RepositoryClassloader.
> My opinion is that the RepositoryClassloader in CocoonServlet is 
> actually not needed if we rely on normal classloading provided by the 
> container. If the container doesn't provide the right classloader, then 
> we should use the ParanoidCocoonServlet that totally shields the 
> upper-level classloaders with its own ParanoidClassloader, which for 
> sure here must be the context classloader.

I agree.  Hopefully, most containers can "do the right thing", and those
that need this non-standard behavior can set the appropriate settings in
web.xml.  Throwing JAR files and classes "wherever" and then tweaking
Cocoon's options to make it work will certainly only create more

> So in short, my proposal is : remove classloading stuff in CocoonServlet 
> and move it to ParanoidCocoonServlet. Of course, classpath computation 
> is left unchanged in CocoonServlet.
> Thoughts ?

I think this is a good idea.


To unsubscribe, e-mail:
For additional commands, email:

View raw message