I hope that we can remove some of the old class loader/class path handling in 2.2 and make everything simpler.
In 2.1.x we had a boolean parameter (in web.xml) which could be used to set the Cocoon class loader (the one used to instantiate Cocoon) as the thread context class loader. 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? Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
