Sorry hit the send button to quick...
The biggest ding against the equinox code is the license. The code
is not apache licensed so I can't for it to Geronimo and I'm not an
equinox committer so I can't get changes in. Even if I did get the
changes in, I'd have to wait for a release anytime we wanted a change
to the class loader. Considering how critical the CL is to Geronimo,
I think we should have the code in our tree.
-dain
On Apr 8, 2006, at 3:01 PM, Dain Sundstrom wrote:
one-jar only supports one level of nesting
I'm not a fan of the equinox code base. I normally spend forever
searching for stuff and then the code is very weird since they seem
to be supporting super old versions of java.
Thanks for the links, but the emory code will be easy to work with.
-dain
On Apr 8, 2006, at 2:47 PM, Sachin Patel wrote:
Dain,
I'm not sure if this helps or not... http://one-
jar.sourceforge.net/. Also I think equinox recently added support
for packaged bundles containing nested jars.
- sachin
On Apr 7, 2006, at 10:40 PM, Dain Sundstrom wrote:
On Apr 7, 2006, at 7:21 PM, John Sisson wrote:
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.
Also need to ensure/test that a security manager policy file can
grant permissions for all JARS in a CAR or individual nested
JARs using a codebase URL in the policy file so users have the
same level of control they would have had in the config-store
(at the same time solving the issue with the policy files
needing to be changed due to the numbered directories in the
config-store):
http://mail-archives.apache.org/mod_mbox/geronimo-user/
200602.mbox/[EMAIL PROTECTED]
%3e
I'm planing starting with the emory university resource class
loader which supports all the security stuff like URLClassLoader,
but is public domain and much more modular. Specifically, I
think it will be easy to implement nested jar support via
unpacking to a temp directory.
-dain
