Hi Donald, thanks for the suggestion -- I shall investigate....
Donald Woods wrote:
#2, intercepting all, sounds like the best solution.
Is this something AspectJ could handle, via an aspect that uses around()
to intercept URLClassLoder construction (but somehow exclude our
creation of them) and constructs/returns our MultiParentClassloader
instead?
To get started, you could use a before() aspect and log an error when
URLClassLoaders are created, just to prove that this could work....
http://www.eclipse.org/aspectj/doc/released/progguide/examples-basic.html
-Donald
Tim McConnell wrote:
Hi, There is at least one scenario using Axis2 and Geronimo that is
causing jarfiles to get locked on Windows such that a deployed WAR
cannot be either redeployed or uninstalled. Here is a brief
description of the failing scenario:
1. A WAR file containing various Axis2 jarfiles in the /lib directory
(axis2-kernel-1.4, axis2-adb-1.4, axis2-spring) is deployed on the
Tomcat version of Geronimo 2.1.3
2. Navigate to the deployed app's address to generate the WSDL for the
web service
3. Redeploy or uninstall of the WAR will now fail since all the
jarfiles in the WAR /lib directory are locked by Windows and cannot be
deleted.
What appears to be happening is that there are three Axis2
URLClassLoaders in this scenario and at least two of them are creating
their own ClassPath and URLClassPath$JarLoader objects that apparently
are locking the jarfiles in the /lib directory. I know that Geronimo
has the JarFileClassloader and MultiParentClassloader classes to
address this problems of this type but unfortunately they don't really
come into play here since the Axis2 libraries are embedded in the
WAR's /lib directory. I also know that this has been a problem on
Windows for a long time (at least 2003 -- see Java Bug ID:4950148) and
probably won't be fixed in the JDK in the immediate future if ever.
And finally I know that this may not actually be a Geronimo problem
but nevertheless appears as just that to the Geronimo end-user(s).
Here is what I've tried up to now with varying degree of success:
1. Moved all the jarfiles out of WAR file into Geronimo's shared-lib
directory added a dependency to the geronimo-web.xml file. This
fortunately does work and provides a fairly simple work-around but
still doesn't fix the underlying problem.
2. Tried the corresponding Axis2-1.4.1 jarfiles (that were just
recently released) but they didn't fix the problem.
3. I was hoping that by using reflection I could clear out some of the
private variable in the ClassLoader to mitigate this problem. But this
causes errors in the JVM whenever the private variables (e.g.
"classes) are updated via reflection.
I wonder if there are other alternatives that I can pursue ?? Kevan
has suggested at least two:
1. Ask Axis2 to change their ClassLoader using the same techniques
that Geronimo employs with JarFileClassLoader and MultiParentClassLoader
2. Intercept instantiations of URLClassLoader in Geronimo and change
them to our own MultiParentClassLoader. I really like this idea since
it would be an all-encompassing solution and not specific to just
Axis2, but I don't know how difficult this might be.
Does anyone have any other suggestions and/or recommendations that I
can or should attempt ??
--
Thanks,
Tim McConnell
