geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hernan Cunico <>
Subject Re: Long Path Proposal
Date Thu, 13 Apr 2006 15:09:31 GMT
I think we should try to make it *simple* for the final user. Having unpacked the jar creates
a mile 
long path that makes it unpractical for anybody to follow, this is totally independent on
whether it 
is supported or not by the OS. We don't need a "paragraph" to describe where a file is, right?

Seeing the Plan B I feel like we are ruling out Windows users by transferring them all these


Can you expand on "in place deployment"? If I get it right, my first impression is that there
not be any direct association (by looking at the FS) between a directory and an application
by Geronimo. Second we could potentially gain some chars but we could equally loose some depending

how you organize your directories and apps. Who would like to have all the apps hanging right
the root

Anyway, I keep thinking simpler is better, of course, it is easier to say it than to fix it


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?
> -dain

View raw message