geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sachin Patel <>
Subject Re: Long Path Proposal
Date Wed, 12 Apr 2006 12:37:00 GMT
Sounds good for me as well.  At what level will WEB-INF/classes be  
jarred? Just the classes themselves or WEB-INF/classes as well?  If  
we can leave the segment "WEB-INF/classes" exploded it may be useful  
users can still drop in class file updates without un/re-jaring.


WEB-INF/classes/classes.jar  would contain org/apache/foo.class
WEB-IN/classes/org/apache/foo.class (user dropped class that takes  
precedence of jarred version.

- sachin

On Apr 11, 2006, at 10:51 PM, David Blevins wrote:

> On Apr 11, 2006, at 6:42 PM, Dain Sundstrom wrote:
>> On Apr 7, 2006, at 2:21 PM, 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.
>> Well, after two days of hacking, I have a class loader that  
>> supports nested jars.  The bad news is the console doesn't run  
>> anymore.  It appears that pluto will only run if the application  
>> is not packed (or not packed in a packed jar).  Anyway, my guess  
>> is that lots of applications will break if the war files are not  
>> available unpacked on the file system.  The second big problem I  
>> am seeing is my new class loader triples the startup time.   
>> Surprisingly, my tests show that the slow startup is not due to  
>> unpacking nested jars, but is over all slowness in the class  
>> loader.  My guess is that the URLClassLoader has some native code  
>> and that the emory class loader I am using isn't doing as much  
>> indexing as the URLClassLoader.  So I think it is time I abandon  
>> my class loader work (to the sandbox) and we start working on a  
>> Plan B:
>> Plan B:
>> o Leave the applications unpacked in the repository.
>> o We should at least warn users when they deploy an application  
>> containing long paths (200+ characters from geronimo home dir) and  
>> maybe offer to jar the WEB-INF/classes if it will fix the problem.
>> o Shorten the geronimo application path by packing the WEB-INF/ 
>> classes
>> o Implement inplace deployment so users can place their  
>> application wherever they want on the file system.
>> Comments?
> Sounds good to me.  I think detecting the problem and clearly and  
> loudly warning the user of it is a very nice consideration to the  
> user -- will save them time.  If we automatically packed their  
> classes and notified the user of that as an additional clear and  
> loud warning message, I think that would be a feature that sets us  
> apart from others.
> -David

View raw message