Make openfire's plugin unloading -> loading more robust


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).




Tom Evans
February 10, 2014, 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, 3:10 PM

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

Daryl Herzmann
February 10, 2014, 3:08 PM

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

What do you think?

Tom Evans
January 16, 2013, 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, 11:57 PM

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

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].



Tom Evans


Daniel Henninger