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 Wed, 12 Apr 2006 01:42:55 GMT
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.



View raw message