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
Acceptance Test - Entry
Activity
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].
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, 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?
Sorry, i won't be brash and reopen without Tom's opinion
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.
