Make openfire's plugin unloading -> loading more robust

Description

Some larger plugins take a while to shut down. We should be able to "watch" the plugin directory more as a plugin is shut down and make sure it's really shut down before we install the updated plugin. I'm envisioning something where you plop down a new .jar, it goes to erase the plugin's directory and sits there and watches until it's really removed. Ie, install new gateway.jar. Remove gateway. Is it gone? No? Wait a second. Remove gateway. Is it gone? No? Wait a second. Remove gateway. Is it gone? It is? good, install new gateway. With some sort of timeout of course.. maybe try 5 times or something and if it fails throw some sort of error back to the user (especially if done via the admin console).

Environment

None

Activity

Tom Evans 
February 10, 2014 at 4:10 PM

I suspect the issue with packed jar files is related to the build rather than the plugin class loader, but I will take a look and report back shortly.

Daryl Herzmann 
February 10, 2014 at 3:10 PM

Sorry, i won't be brash and reopen without Tom's opinion

Daryl Herzmann 
February 10, 2014 at 3:08 PM

@Tom Evans, I suspect the change to PluginClassLoader.java is causing the current troubles with Openfire not loading packed files?

http://community.igniterealtime.org/message/235675

What do you think?

Tom Evans 
January 16, 2013 at 12:11 AM

Keep track of each jar file loaded by a plugin, then unload the corresponding resource(s) when the plugin is unloaded/destroyed.

[SVN 13395]

Tom Evans 
January 15, 2013 at 11:57 PM

This is related to a long-standing class loader bug:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4167874

The bug is reportedly fixed in JRE7, but as Openfire is still using JRE5 we have prepared a workaround solution for the PluginManager [commit pending].

Fixed

Details

Assignee

Reporter

Components

Fix versions

Affects versions

Priority

Created November 1, 2007 at 7:51 PM
Updated February 10, 2014 at 4:10 PM
Resolved February 10, 2014 at 3:10 PM