Nested Jars [was: JarFileClassLoader]

[Dain Sundstrom <da...@iq80.com>]

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

Re: Nested Jars [was: JarFileClassLoader]

[Davanum Srinivas <da...@gmail.com>]

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 <da...@iq80.com> 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 : http://wso2.com/blogs/