Carsten Ziegeler wrote:
Reinhard Poetz wrote:
As described in the comment above, classes in [block]/COB-INF/classes are added
to the classpath. The information, which blocks are added, is read out from
wiring.xml.
While doing this, I've (hopefully) cleaned up our classloading abit as I've
moved all the code into CoreUtil. I've tested OSGi and the per sitemap
classloader and both work as expected. Hopefully others can verify, expecially
if you can test with other servlet containers than Jetty.
If others are interested in helping us getting blocks (+ binary distributions)
sooner and want to do more than just talking, have a look at the open tasks
above :-p
I hope that we can remove some of the old class loader/class path
handling as well.
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.
Does it mean I will be forced to have xalan/xerces in cocoon's
web-inf/lib directory? Right now the only place is jetty/lib/endorsed.
--
Leszek Gawron [EMAIL PROTECTED]
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
