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
