Return-Path: Delivered-To: apmail-jakarta-avalon-phoenix-dev-archive@apache.org Received: (qmail 28576 invoked from network); 13 Jul 2002 06:15:26 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 13 Jul 2002 06:15:26 -0000 Received: (qmail 3940 invoked by uid 97); 13 Jul 2002 06:15:50 -0000 Delivered-To: qmlist-jakarta-archive-avalon-phoenix-dev@jakarta.apache.org Received: (qmail 3878 invoked by uid 97); 13 Jul 2002 06:15:49 -0000 Mailing-List: contact avalon-phoenix-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon-Phoenix Developers List" Reply-To: "Avalon-Phoenix Developers List" Delivered-To: mailing list avalon-phoenix-dev@jakarta.apache.org Received: (qmail 3866 invoked by uid 98); 13 Jul 2002 06:15:48 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Message-ID: <3D2FC572.5070505@tanukisoftware.com> Date: Sat, 13 Jul 2002 15:15:14 +0900 From: Leif Mortenson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc2) Gecko/20020512 Netscape/7.0b1 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: Avalon-Phoenix Developers List Subject: Re: Sevak and the tools.jar file References: <5.1.0.14.2.20020712123646.01b78a20@www.stocksoftware.com.au> <5.1.0.14.2.20020712141537.01b3dd50@www.stocksoftware.com.au> <5.1.0.14.2.20020713084609.01d00e98@www.stocksoftware.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Peter, It sounds like there are 3 classloader scopes that we have to set up. 1) Is the launcher. This classloader should have access to phoenix-loader.jar and wrapper.jar but nothing else. 2) The actual Phoenix Container. This classloader will have access to the container specific jars as well as a set of common jars. 3) The applications. These classloaders will have access to the set of common jars, the contents of the ext directory and the lib and classes directories in their SAR-INF directories. If this is the case, then why not use a direcory structure like the following: lib/ (launcher jars) lib/phoenix-loader.jar lib/wrapper.jar lib/Wrapper.DLL or libwrapper.so lib/container (container jars) lib/common (common jars) lib/ext (extension jars) This way the bin directory could be kept clean I will admit that I am a little unclear as to which jars are needed where as far as the #2 / #3 classloaders I have not really delved into the Phoenix code much past the launcher. I could go in making changes like a bull in a china shop, but that would probably be unadvisable <:-) For example, I have not figured out where in the existing code, the jars in ext are being loaded. Sevak is unable to find tools.jar if I place it there. Currently it has to be in the lib directory. This seems to have turned into a bigger project than I was originally planning to take on right now <:-} I moved all of the lib jars into the bin/lib directory. But was unable to start Phoenix with Sevak. It seemed to require that logkit, framework, excalibur-containerkit, ant excalibur-i18n be in the common lib directory. Leif > right. The ext dir is there for applications that contain jars that > declare "Optional Dependecies"/"Extensions". The extensions will > attempt to be loaded from the ext dir. SO if > myapp/SAR-INF/lib/cornerstone.jar had something like > > Extension-List: foo > foo-Extension-Name: Foo API > foo-Specification-Version: 1.1 > ... > > Then phoenix would try and find the "foo" library in ext dir. > > As the lib directory was not being included in the initial class > path to load the JVM, I assumed > >> that the Main class would be adding the files there and using them to >> load the rest of Phoenix. >> But that does not appear to be happening right now. Main finds the >> phoenix-engine.jar, but the >> other jars are only available because of the -Djava.ext.dirs property. > > > I just updated the code so that aall of the libraries contianed in > $PHOENIX_HOME/bin/lib are loaded into the Containers classloader (not > visible from .sar files). So thus we can create adirectory like > > jakarta-avalon-phoenix/lib/container > > and have all of its jars copied to dist/bin/lib. > > SO these are all the jars that are not shared with .sar files (CLI, > Baxter, logkit, excalibur-logger, jmx, containerkit....) > > How does that sound? > >> I think that the needed fix is to create a method in Main which >> creates a classpath of all jar and >> zip files in the lib and ext directories. This classpath will then >> be used to load and launch the >> CLIMain class. Currently, the phoenix-engine.jar file is located in >> the bin directory and then >> all other classes are found in the "JVM ext" directory. > > > done. > >> Doing this would also make it possible to move the >> phoenix-engine.jar file into the lib directory. >> Is there any reason why the phoenix-loader.jar file is not over there >> as well? > > > > Mainly to isolate the apps from changes in the container. ie We have > had a few bug reports when we upgraded threading because > cornerstone.jar was relying on previous version of libraries being in > dist/lib . > > Having all the container jars in separate jar helps us avoid these > issues ... hopefully ;) > > > >> Also: >> Any reason why the following is in the dist-lite task? > > > no idea. > > Cheers, > > Peter Donald > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > "Faced with the choice between changing one's mind, > and proving that there is no need to do so - almost > everyone gets busy on the proof." > - John Kenneth Galbraith > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > -- > To unsubscribe, e-mail: > > For additional commands, e-mail: > > > -- To unsubscribe, e-mail: For additional commands, e-mail: