geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Prasad Kashyap" <goyathlay.geron...@gmail.com>
Subject Re: Long Path Proposal
Date Thu, 13 Apr 2006 15:23:32 GMT
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
project.properties. 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 <dain@iq80.com> 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
> >>
>
>

Mime
View raw message