-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 May i suggest a variant of #1? Help Axis2 folks with a patch that fixes the problem?
thanks, dims 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 ?? > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIymTCgNg6eWEDv1kRApHxAKDsFCKO6Z2fNGooWWkRk0zBox6SfACeNFOg dlUV3fisS0tXTcsAinuLF6c= =bwBS -----END PGP SIGNATURE-----
