avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leif Mortenson <l...@tanukisoftware.com>
Subject Re: Sevak and the tools.jar file
Date Sat, 13 Jul 2002 06:15:14 GMT
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:   
> <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
> <mailto:avalon-phoenix-dev-help@jakarta.apache.org>
>
>



--
To unsubscribe, e-mail:   <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>


Mime
View raw message