SystemProperty: Remember the classloader which loaded a class #2000
Conversation
Following happened to me: 1. Set a custom LockoutProvider class which is located in a plugin 2. During authentication, the LockOutManager.getInstance() was called for the first time and tried to load the custom LockoutProvider class. It failed, because JiveClassLoader could not find it (it's the classloader used in auth code). This commit sets the classloader whenever a class is set in a property via the setValue() method. When getValue() is called, the classloader associated with the set class can be used to load the class with the correct classloader. This does not work during the initial start of Openfire if properties are loaded statically, but if a plugin later sets its own class and Openfire code then tries to load this class (in my example during authentication), it can use the correct classloader. Current workaround is to call LockOutManager.getInstance() in the plugin code, so that it already initialized with the custom lockout provider and does not try to load the class during authentication.
|
Thanks for the PR @sco0ter. Did you check how this behaves around the various stages of a plugin lifecycle? I'm worried that the reference to a (plugin)classloader causes plugins that provide classes that are refenced by this implempentaiton keep them from being garbage collected when they are unloaded/reloaded/updated. This has proven to have particularly nasty side-effects (effectively having two versions of the same plugin partially loaded). As an aside: battling classloading-related issues with Openfire plugins is often a signal to me to start checking if it is worthwhile to have a particular piece of functionality being implemented as a plugin in the first place. Plugins provide ease of deployment, but can also be unloaded/replaced at runtime. For certain functionality (especially around things like authentication), this might not be very desirable. In such cases, it's worth considering moving the functionality in a plain old non-plugin library / jar file, that's added in Openfire's |
|
No I did not check that. I am afraid, I have no time to investigate into the lifecycle and classloading and garbarge collection stuff. Thanks for the hint with the lib folder. We avoid messing around with it, though, and keep custom logic in plugins. |
|
In the (distant) past, when I had to do something similar, I had the plugin check the core Openfire class loader (not the default, plugin class loader) for the existence of a class in the custom .jar file. If it wasn't there, you can either shutdown Openfire with logs reporting why, or on the plugin admin screens highlight that the .jar file needs copying from the plugin/lib to the openfire/lib folder and restart Openfire manually. |
|
👋 @sco0ter, do you still have interest pushing this PR over the finish line? |
|
Sorry, no. I am out of business with Openfire. |
Following happened to me:
This commit sets the classloader whenever a class is set in a property via the setValue() method. When getValue() is called, the classloader associated with the set class can be used to load the class with the correct classloader.
This does not work during the initial start of Openfire if properties are loaded statically, but if a plugin later sets its own class and Openfire code then tries to load this class (in my example during authentication), it can use the correct classloader.
Current workaround is to call LockOutManager.getInstance() in the plugin code, so that it already initialized with the custom lockout provider and does not try to load the class during authentication.