I think we should try to make it *simple* for the final user. Having unpacked the jar creates a mile
long path that makes it unpractical for anybody to follow, this is totally independent on whether it
is supported or not by the OS. We don't need a "paragraph" to describe where a file is, right?
Seeing the Plan B I feel like we are ruling out Windows users by transferring them all these
limitations.
Can you expand on "in place deployment"? If I get it right, my first impression is that there would
not be any direct association (by looking at the FS) between a directory and an application served
by Geronimo. Second we could potentially gain some chars but we could equally loose some depending
how you organize your directories and apps. Who would like to have all the apps hanging right from
the root
Anyway, I keep thinking simpler is better, of course, it is easier to say it
than to fix it ;)
Cheers!
Hernan
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?
-dain
