cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <>
Subject RE: ClassLoader issues
Date Mon, 10 Jun 2002 19:06:05 GMT
> From: Sylvain Wallez []

> After some investigation in CocoonServlet's classloading stuff (which
> has a loooong history), it appears to me that classpath and
> are different issues and that we don't really need the
> RepositoryClassloader there. Discussion follows...
> The classpath is used to instruct the Java compiler used for XSPs
> it should find the classes, since it (unfortunately) doesn't care
> the current classloader. So the extra-classpath parameter is IMO
> 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).
> Now Cocoon relies heavily on dynamic loading of classes named in
> cocoon.xconf and sitemap.xmap through Avalon, and to avoid
> 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
> WEB-INF/lib), all classloading is made using the current thread's
> context classloader.
> 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,
> 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.
> So in short, my proposal is : remove classloading stuff in
> and move it to ParanoidCocoonServlet. Of course, classpath computation
> is left unchanged in CocoonServlet.
> Thoughts ?

No objections if it works.

I think this hack was done long before ParanoidCocoonServlet was
created, and now it seems it should be moved to ParanoidCocoonServlet.


> Sylvain
> --
> Sylvain Wallez
>  Anyware Technologies                  Apache Cocoon

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

View raw message