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 18:13:37 GMT
I don't know exactly how we do the auto jar, but I would think that  
we would put the generated jar at WEB-INF/lib/somename.jar.   This  
would only happen when people install applications into the  
repository, which I would hope it not the normal case for  
development, so I'm not sure we need to leave the WEB-INF/classes dir  
in the class path.  Then again, there most likely isn't any harm in  
doing it.


On Apr 12, 2006, at 5:37 AM, Sachin Patel wrote:

> 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.
> So...
> 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