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
