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 6.2.4.8 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 > http://jakarta.apache.org/tomcat/tomcat-4.0-doc/class-loader-howto.html > 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 problems. > > 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. David --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
