cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <>
Subject Re: [RT] Clarifying classloading in 2.2 [was Re: Classloader changes]
Date Mon, 10 Oct 2005 14:21:26 GMT
> In addition, we could define extra class paths in web.xml (containing
> directories/jars I think) which were added to the class path as  
> well and
> finally we have parameters to force load classes (e.g. for jdbc  
> drivers).
> With real blocks I think we should always add our class loader as the
> thread context CL (this is the current implementation) and we should
> forget about defining additional class paths.
> I'm not sure about the force loading stuff.
> In addition I think we should always use the paranoid class loader to
> avoid class loading problems. A common problem are either Xalan and
> Xerces where you forgot to put the latest version (used by Cocoon)  
> into
> the endorsed lib. Or if the application server uses his own version of
> let's say commons-logging/log4j and you want to use a different one in
> Cocoon.
> So, the most important question is: does using an own class loader
> inside a web app work in all engines, is it allowed, and is it allowed
> to set the thread context CL?

We are already using the paranoid classloader
from within the sitemap if there is a map:classpath
element. It is being used for the hot reloading
of classes, components and javaflow.

Did you leave before my presentation?


View raw message