Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Mime-Version: 1.0 (Apple Message framework v749.3)
In-Reply-To: <0A96A65B-DC1F-48A1-AFD8-0AB7B5FE07B4@iq80.com>
References: <F8E06ADD-4795-4383-AD95-9BEC4CC998A3@iq80.com>
 <44371E36.1030606@gmail.com> <6B331265-956A-4E6A-B5B5-9F94DD7E97BE@iq80.com>
 <0D60B9E4-609C-446D-AE62-8765B097E2A6@gmail.com>
 <0A96A65B-DC1F-48A1-AFD8-0AB7B5FE07B4@iq80.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <79572CE2-9A94-461A-8B2D-5B20323CF43B@iq80.com>
Content-Transfer-Encoding: 7bit
From: Dain Sundstrom <dain@iq80.com>
Subject: Re: Long Path Proposal
Date: Sat, 8 Apr 2006 15:04:23 -0700
To: dev@geronimo.apache.org

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.

-dain

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- 
>> jar.sourceforge.net/.  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):
>>>>
>>>> http://mail-archives.apache.org/mod_mbox/geronimo-user/ 
>>>> 200602.mbox/%3c20060210144645.87917.qmail@web54302.mail.yahoo.com 
>>>> %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