geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davanum Srinivas" <>
Subject Re: Nested Jars [was: JarFileClassLoader]
Date Thu, 04 May 2006 17:44:00 GMT
Woohoo!!! I love it. my 2 cents is to go with 4b). Thanks a ton for
the write up.

-- dims

On 5/4/06, Dain Sundstrom <> wrote:
> On May 4, 2006, at 1:18 AM, Davanum Srinivas wrote:
> > Dain,
> >
> > Does this support resources/classes from a jar within jar?
> >
> > jar:jar:file:/c:/xyz/abc.jar!/lib/xyz.jar!/META-INF/myService/
> > services.xml
> No, but it will :)
> I'm not sure when I will get time to add support, but our
> NestedJarFile code handles cases, all combinations of nested packed
> jars and unpacked jars.  This is the same code we use for deployment,
> which is agnostic of the packed or unpacked state of an archive. For
> example
>    jar:jar:file:/foo.ear!/foo.war!/WEB-INF/lib/classes/
> The ear could unpacked, with the war packed.  The ear could be packed
> with the war unpacked inside of it.
> Of course no good deed goes unpunished...  One nice thing about the
> JarFileClassLoader is it works without installing any
> URLStreamHandlers.  As we all know installing a URLStreamHandler is
> difficult, error prone, and in some embedded scenarios basically
> impossible.  I am confident I can add supported for nested jars into
> the JarFileClassLoader without requiring you to install a
> URLStreamHandler, but code that do url manipulation will most likely
> require a URLStreamHandler to be installed that can handle the nested
> jar syntax.  For example, the following code will not work without a
> new handler installed:
>    URL url = ClassLoader.getResource(foo);
>    URL newURL = new URL(url.toString() + "/bar");
> This kind of code is extremely common in user apps.  If we do not
> install a new URLStreamHandler for the jar protocol, the user will
> get an exception when opening the stream, because the url string will
> be something like "jar:jar:file:some.ear!/some.war!/foo/bar".
> So where are we?
> 1) I'll extend the JarFileClassLoader to support nested jar (most
> likely after 1.1 and after it is moved back to xbean-classloader)
> 2) The nested jar support in the class loader will not require a new
> URLStreamHandler to be installed.
> 3) URL manipulation by app code will only need a URLStreamHandler to
> be installed if they do not build urls using new URL(baseUrl, "foo");
> 4) We will need to offer and install a URLStreamHandler for code that
> does jar manipulation.  For that we have two options (we may want both).
>      a) Install new URLStreamHandler for the jar protocol.  This
> would support the extended syntax and GC file handles.  It is
> difficult to override a protocol shipped with the VM, so we may want to
>      b) Install new URLStreamHandler for a new protocol say xjar.
> This can be the same code as above but uses a different protocol
> name.  This should easier to install since it is extension and not
> replacement.  In this case nested jar URLs returned from the class
> loader would use the xjar protocol, and non nested jars would use the
> jar protocol.
> So the only thing to decide is 4a or 4b.  One other important thing
> to note is that any code written to assume nested jar urls are valid,
> will only work on a platform with a replaced jar URLStreamHandler.
> Also, I still don't think we should use this for loading user
> application since many user apps can't handle nested jars or assume
> that they are unpacked.
> -dain

Davanum Srinivas :

View raw message