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 Thu, 13 Apr 2006 17:58:15 GMT
I got that patch working with the jmxdebug web app, and committed the  
work.  Can you look at applying this to the rest of the web  


On Apr 13, 2006, at 8:23 AM, Prasad Kashyap wrote:

> When I tried to jar up the classes of the servlet-examples, the app
> did not start. It failed with ClassNotFoundException.
> Anyways, here is a small patch to jar up the files under
> WEB-INF/classes and place it under WEB-INF/lib/classes.jar. The files
> under classes dir are then deleted.
> This option is triggered by a a maven.war.usesJar flag in the
> It would have been ideal to replace the war:webapp
> goal from the maven plugin which is where the WEB-INF/classes dir is
> created in the first place. But since we can't get to it, I am using a
> postGoal on that war:webapp goal.
> Cheers
> Prasad
> On 4/12/06, Dain Sundstrom <> wrote:
>> 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.
>> -dain
>> 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
>> <console-standard.patch>
>> <start.log>

View raw message