geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim McConnell <>
Subject [DISCUSS] URLClassloader problem
Date Fri, 12 Sep 2008 02:40:16 GMT
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 ??

Tim McConnell

View raw message