Re: [RT] Clarifying classloading in 2.2 [was Re: Classloader changes]

[Torsten Curdt]

In addition, we could define extra class paths in web.xml (containing



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

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?

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). Xerces where you forgot to put the latest version (used by Cocoon) into

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?

cheers
--
Torsten

PGP.sig
Description: This is a digitally signed message part