From nick@technisys.com.ar Wed Dec 13 14:35:57 2000 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 44494 invoked from network); 13 Dec 2000 14:35:57 -0000 Received: from venus.tis.com.ar (63.69.231.252) by locus.apache.org with SMTP; 13 Dec 2000 14:35:57 -0000 Received: from [10.1.2.106] (helo=technisys.com.ar) by venus.tis.com.ar with esmtp (Exim 3.12 #1 (Debian GNU/Linux)) id 146D2P-0003l5-00; Wed, 13 Dec 2000 11:37:45 -0300 Message-ID: <3A378932.8060508@technisys.com.ar> Date: Wed, 13 Dec 2000 11:35:30 -0300 From: =?ISO-8859-1?Q?Nicol=E1s?= Lichtmaier User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.18pre24 i686; en-US; m18) Gecko/20001212 X-Accept-Language: en MIME-Version: 1.0 To: Robin Green CC: cocoon-dev@xml.apache.org Subject: Re: Reunning separate instances of Cocoon in the same JVM (patch) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N > 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.