cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: ClassLoader issues
Date Mon, 10 Jun 2002 18:38:10 GMT
David Haraburda wrote:

>Hi,
>
>On Sun, 2002-06-09 at 16:28, Nicola Ken Barozzi wrote:
>  
>
>>The real reason: Cocoon is not a Servlet.
>>Cocoon conceptually lives in the same space of Tomcat, not on top of it.
>>    
>>
>
>I certainly agree that conceptually Cocoon is much more than a simple
>servlet -- it is a large and complex system.  However in actuality it
>runs as a web application, so I think it is only appropriate that it
>acts in compliance with the necessary specifications.
>
>  
>
>>Cocoon is generally a servlet out of need, since it eases deployment on
>>existing systems.
>>
>
>I can understand with a large project like Cocoon, many things will have
>to be done that a normal web application wouldn't do -- the main issue I
>am trying to raise here is that I feel it is unnecessary for Cocoon to
>ever override the ContextClassLoader -- and I appreciate any and all
>feedback on this.
>

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 ?

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