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 <[EMAIL PROTECTED]> 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/
