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:12:31 GMT
Hi Jarek, Thanks for the suggestion for actually trying to close the jarfile. It 
is not something I considered nor tried, but it is very easy to do so.....

Jarek Gawor wrote:
> Primarily, this is a problem in Axis2 and it should be fix there no
> matter what we do about it (if anything) in Geronimo. But I'm not even
> sure what we can do about it in Geronimo. Maybe we can intercept class
> loading of "" and return our own replacement
> for it (right now we have a ClassLoader that extends URLClassLoader
> that's its in own package but I think we would need something in the
> "" package). So I'm definitely for #1 but I don't know what we
> can do about #2.
> Btw, did you try closing the JarFile of JarLoader using reflection?
> Conceptually, something like:
> URLClassLoader classLoader = ...;
> for (Object loader : classLoader.ucp.lmap.values()) {
>    loader.jar.close();
> }
> Jarek
> On Thu, Sep 11, 2008 at 10:40 PM, 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 ??
>> --
>> Thanks,
>> Tim McConnell

Tim McConnell

View raw message