You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Dain Sundstrom <da...@iq80.com> on 2006/05/04 05:08:46 UTC
JarFileClassLoader
I added a new optional class loader to 1.1 which should fix our file
lock problem on Windows. To enable the class loader use the
following command line option:
-DXorg.apache.geronimo.NewClassLoader=true
If the class loader actually solves the problem, and passes the TCK
we can make it the default.
If you are a Windows user, please try it out and report any remaining
file lock problems.
If you have some free time please take a look at the code. This type
of code needs lots of eyes on it. The code is located at branches/
1.1/modules/kernel/src/java/org/apache/geronimo/kernel/classloader.
I suggest you start with JarFileClassLoader, but the real file
management code is in JarFileResourceFinder.
-dain
Re: JarFileClassLoader
Posted by Prasad Kashyap <go...@gmail.com>.
It works.
http://issues.apache.org/jira/browse/GERONIMO-1979#action_12377698
http://issues.apache.org/jira/browse/GERONIMO-1925#action_12377695
Cheers
Prasad
On 5/4/06, John Sisson <jr...@gmail.com> wrote:
> I retested GERONIMO-1954 and the new classloader fixed the problem with
> files not being cleaned up when there is a deployment error.
>
> I haven't done any other testing with it enabled yet.
>
> John
>
> Dain Sundstrom wrote:
> > I added a new optional class loader to 1.1 which should fix our file
> > lock problem on Windows. To enable the class loader use the following
> > command line option:
> >
> > -DXorg.apache.geronimo.NewClassLoader=true
> >
> > If the class loader actually solves the problem, and passes the TCK we
> > can make it the default.
> >
> > If you are a Windows user, please try it out and report any remaining
> > file lock problems.
> >
> > If you have some free time please take a look at the code. This type
> > of code needs lots of eyes on it. The code is located at
> > branches/1.1/modules/kernel/src/java/org/apache/geronimo/kernel/classloader.
> > I suggest you start with JarFileClassLoader, but the real file
> > management code is in JarFileResourceFinder.
> >
> > -dain
> >
>
>
Re: JarFileClassLoader
Posted by John Sisson <jr...@gmail.com>.
I retested GERONIMO-1954 and the new classloader fixed the problem with
files not being cleaned up when there is a deployment error.
I haven't done any other testing with it enabled yet.
John
Dain Sundstrom wrote:
> I added a new optional class loader to 1.1 which should fix our file
> lock problem on Windows. To enable the class loader use the following
> command line option:
>
> -DXorg.apache.geronimo.NewClassLoader=true
>
> If the class loader actually solves the problem, and passes the TCK we
> can make it the default.
>
> If you are a Windows user, please try it out and report any remaining
> file lock problems.
>
> If you have some free time please take a look at the code. This type
> of code needs lots of eyes on it. The code is located at
> branches/1.1/modules/kernel/src/java/org/apache/geronimo/kernel/classloader.
> I suggest you start with JarFileClassLoader, but the real file
> management code is in JarFileResourceFinder.
>
> -dain
>
Re: JarFileClassLoader
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
This sounds pretty nice. I'm not sure I have the will to set up a
Geronimo environment on Windows to try it, but it would be really cool
if we avoided all the file locking problems caused by the jar handling
there. :)
Thanks,
Aaron
On 5/3/06, Dain Sundstrom <da...@iq80.com> wrote:
> I added a new optional class loader to 1.1 which should fix our file
> lock problem on Windows. To enable the class loader use the
> following command line option:
>
> -DXorg.apache.geronimo.NewClassLoader=true
>
> If the class loader actually solves the problem, and passes the TCK
> we can make it the default.
>
> If you are a Windows user, please try it out and report any remaining
> file lock problems.
>
> If you have some free time please take a look at the code. This type
> of code needs lots of eyes on it. The code is located at branches/
> 1.1/modules/kernel/src/java/org/apache/geronimo/kernel/classloader.
> I suggest you start with JarFileClassLoader, but the real file
> management code is in JarFileResourceFinder.
>
> -dain
>
Re: Nested Jars [was: JarFileClassLoader]
Posted by 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/
Nested Jars [was: JarFileClassLoader]
Posted by 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: JarFileClassLoader
Posted by Davanum Srinivas <da...@gmail.com>.
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
thanks,
dims
On 5/3/06, Dain Sundstrom <da...@iq80.com> wrote:
> I added a new optional class loader to 1.1 which should fix our file
> lock problem on Windows. To enable the class loader use the
> following command line option:
>
> -DXorg.apache.geronimo.NewClassLoader=true
>
> If the class loader actually solves the problem, and passes the TCK
> we can make it the default.
>
> If you are a Windows user, please try it out and report any remaining
> file lock problems.
>
> If you have some free time please take a look at the code. This type
> of code needs lots of eyes on it. The code is located at branches/
> 1.1/modules/kernel/src/java/org/apache/geronimo/kernel/classloader.
> I suggest you start with JarFileClassLoader, but the real file
> management code is in JarFileResourceFinder.
>
> -dain
>
--
Davanum Srinivas : http://wso2.com/blogs/