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 Vadim
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
