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 <[EMAIL PROTECTED]> 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
Description: Binary data
start.log
Description: Binary data
