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