geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Long Path Proposal
Date Sat, 08 Apr 2006 22:04:23 GMT
Sorry hit the send button to quick...

The biggest ding against the equinox code is the license.  The code  
is not apache licensed so I can't for it to Geronimo and I'm not an  
equinox committer so I can't get changes in.  Even if I did get the  
changes in, I'd have to wait for a release anytime we wanted a change  
to the class loader.  Considering how critical the CL is to Geronimo,  
I think we should have the code in our tree.


On Apr 8, 2006, at 3:01 PM, Dain Sundstrom wrote:

> one-jar only supports one level of nesting
> I'm not a fan of the equinox code base.  I normally spend forever  
> searching for stuff and then the code is very weird since they seem  
> to be supporting super old versions of java.
> Thanks for the links, but the emory code will be easy to work with.
> -dain
> On Apr 8, 2006, at 2:47 PM, Sachin Patel wrote:
>> Dain,
>> I'm not sure if this helps or not... http://one- 
>>  Also I think equinox recently added support  
>> for packaged bundles containing nested jars.
>> - sachin
>> On Apr 7, 2006, at 10:40 PM, Dain Sundstrom wrote:
>>> On Apr 7, 2006, at 7:21 PM, John Sisson wrote:
>>>> Dain Sundstrom wrote:
>>>>> Unpacked archives in the repository:
>>>>> The solution is to not place unpacked archives in our  
>>>>> repository.  I (dain) am going to look at using a class loader  
>>>>> that can read from classes and resources from jars nested in  
>>>>> jars.  Assuming we can find or write a class loader such a  
>>>>> class loader, we will need to assure that Tomcat and Jetty can  
>>>>> work from a packed archive.
>>>> Also need to ensure/test that a security manager policy file can  
>>>> grant permissions for all JARS in a CAR or individual nested  
>>>> JARs using a codebase URL in the policy file so users have the  
>>>> same level of control they would have had in the config-store  
>>>> (at the same time solving the issue with the policy files  
>>>> needing to be changed due to the numbered directories in the  
>>>> config-store):
>>>> 200602.mbox/ 
>>>> %3e
>>> I'm planing starting with the emory university resource class  
>>> loader which supports all the security stuff like URLClassLoader,  
>>> but is public domain and much more modular.  Specifically, I  
>>> think it will be easy to implement nested jar support via  
>>> unpacking to a temp directory.
>>> -dain

View raw message