cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: [RT] Clarifying classloading in 2.2 [was Re: Classloader changes]
Date Mon, 10 Oct 2005 17:48:47 GMT
Carsten Ziegeler wrote:
> 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

IIRC, those were *not* added to the classpath, but on the contrary - it was a 
way to indicate to the java compiler (used in xsp, for example) about any 
classpath which was set in the container.

For example, if you have some extra lib in the tomcat/common/lib, it is visible 
to Cocoon but java compiler does not know about it, hence the need to specify 
extra class path elements.

This can be avoided if javac knew how to work with class loader - as jdt does.

> In addition I think we should always use the paranoid class loader to
> avoid class loading problems.

I don't like using paranoid class loader always. I prefer current situation 
where you can choose what you need.

> A common problem are either Xalan and
> Xerces where you forgot to put the latest version (used by Cocoon) into
> the endorsed lib.

This problem is not existent anymore on jdk1.5


> 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?
> Carsten

View raw message