geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <>
Subject Re: [DISCUSS] URLClassloader problem
Date Fri, 12 Sep 2008 12:46:59 GMT
Hash: SHA1

May i suggest a variant of #1? Help Axis2 folks with a patch that fixes the problem?


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 ??
Version: GnuPG v1.4.6 (GNU/Linux)


View raw message