cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolás Lichtmaier <n...@technisys.com.ar>
Subject Re: Reunning separate instances of Cocoon in the same JVM (patch)
Date Wed, 13 Dec 2000 14:35:30 GMT
> Thanks Nicolas. The first two patches were good. However I don't see 
> the  point of this one. You see, this classpath setting only affects 
> the  compiler, not the classloader. You will not be able to prevent 
> class loading  conflicts using this patch, and you will not be able to 
> add anything to the  classpath that isn't already there.


This is part of the zone file:

# here we configure the local classloader
repositories=/home/nick/src/xml-cocoon/build/classes

repositories=/usr/local/share/java/fop_0_13_0.jar
repositories=/usr/local/share/java/xerces_1_2.jar
repositories=/usr/local/share/java/xalan_1_2_D02.jar
repositories=/usr/local/share/java/xml.jar
repositories=/usr/local/share/java/turbine-pool.jar

# and here we tell cocoon to compile with this classpath added to the 
system one.
servlet.org.apache.cocoon.Cocoon.initArgs=processor.xsp.localclasspath= 
/home/nick/src/java:/home/nick/src/xml-cocoon/build/classes: (the same 
classpath as before)

Explanation:

The classloader is already configured. The classloader already knows 
abou the local classpath, but Cocoon was compiling using only the system 
one. The ideal way of doing this would be te existence of a 
getClasspath() method in the ClassLoader class and discover the current 
classpath dynamically.


Mime
View raw message