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 Fri, 19 Sep 2008 22:13:15 GMT
Hi Donald, thanks for the suggestion -- I shall investigate....

Donald Woods wrote:
> #2, intercepting all, sounds like the best solution.
> Is this something AspectJ could handle, via an aspect that uses around() 
> to intercept URLClassLoder construction (but somehow exclude our 
> creation of them) and constructs/returns our MultiParentClassloader 
> instead?
> To get started, you could use a before() aspect and log an error when 
> URLClassLoaders are created, just to prove that this could work....
> -Donald
> 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