cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <vadim.gritse...@verizon.net>
Subject RE: ClassLoader issues
Date Mon, 10 Jun 2002 19:06:05 GMT
> From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]

...
 
> 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...
> 
> 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
>
http://jakarta.apache.org/tomcat/tomcat-4.0-doc/class-loader-howto.html
> 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
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.
> 
> 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.
> 
> 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 ?

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.

Vadim


> Sylvain
> 
> --
> Sylvain Wallez
>  Anyware Technologies                  Apache Cocoon
>  http://www.anyware-tech.com           mailto:sylvain@apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message