Hi Jarek, Thanks for the suggestion for actually trying to close the jarfile. It
is not something I considered nor tried, but it is very easy to do so.....
Jarek Gawor wrote:
Primarily, this is a problem in Axis2 and it should be fix there no
matter what we do about it (if anything) in Geronimo. But I'm not even
sure what we can do about it in Geronimo. Maybe we can intercept class
loading of "java.net.URLClassLoader" and return our own replacement
for it (right now we have a ClassLoader that extends URLClassLoader
that's its in own package but I think we would need something in the
"java.net" package). So I'm definitely for #1 but I don't know what we
can do about #2.
Btw, did you try closing the JarFile of JarLoader using reflection?
Conceptually, something like:
URLClassLoader classLoader = ...;
for (Object loader : classLoader.ucp.lmap.values()) {
loader.jar.close();
}
Jarek
On Thu, Sep 11, 2008 at 10:40 PM, Tim McConnell <[EMAIL PROTECTED]> 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
--
Thanks,
Tim McConnell
