Re: Replacing a plugin with a new version does not work without restarting Tomcat

[Jesse Glick]

[from users@]

Kohsuke Kawaguchi wrote:
> Was there a way to forcibly terminate URLClassLoader?

Unfortunately there is not; you can only pray it gets GC'd. For the
NetBeans module system there is a somewhat complex workaround involving
tempFile copies of module JARs marked reloadable; I would not recommend
spending effort on it unless this seems like a serious issue for Hudson
users.

-J.

--
[hidden email]  netbeans.org  ant.apache.org  hudson.dev.java.net
             http://google.com/search?q=e%5E%28pi*i%29%2B1

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Kohsuke Kawaguchi]

Jesse Glick wrote:

> [from users@]
>
> Kohsuke Kawaguchi wrote:
>> Was there a way to forcibly terminate URLClassLoader?
>
> Unfortunately there is not; you can only pray it gets GC'd. For the
> NetBeans module system there is a somewhat complex workaround involving
> tempFile copies of module JARs marked reloadable; I would not recommend
> spending effort on it unless this seems like a serious issue for Hudson
> users.

OK. I guess that's what I was afraid of.

In that case, Hudson should suggest to restart a container, not just Hudson.

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

[Jesse Glick]

Jesse Glick wrote:
>> Was there a way to forcibly terminate URLClassLoader?
>
> Unfortunately there is not; you can only pray it gets GC'd.

Of course you can write your own ClassLoader subclass which explicitly
reads from, and at some defined point closes, a JarFile. You expect
plugin code is well-behaved so that there are no requests for class or
resource loads after termination - if there are, just throw an exception
and hope for the best.

This is not a perfect workaround, though: Class{,Loader}.getResource (as
opposed to .getResourceAsStream) must return a custom URL (either using
a custom protocol, or constructed with a special protocol handler
object); and no code must open a URL it makes for itself via the
URL(String) constructor, since the JRE's jar-protocol handler caches
JarFile's and IIRC never releases them. To be sure this did not happen
you would need to override the JRE's jar protocol handler. Or call
URLConnection.setUseCaches(false) (mistakenly nonstatic).

-J.

--
[hidden email]  netbeans.org  ant.apache.org  hudson.dev.java.net
             http://google.com/search?q=e%5E%28pi*i%29%2B1

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]