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:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
