geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim McConnell <>
Subject Re: [DISCUSS] URLClassloader problem
Date Tue, 07 Oct 2008 03:14:34 GMT
I've opened the following Axis2 JIRA so that I can attach patch(es) to fix this 
specific scenario.

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 ??

Tim McConnell

View raw message