geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <>
Subject Re: Long Path Proposal
Date Wed, 12 Apr 2006 02:51:10 GMT
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.


View raw message