Improve plugin classloader visiblity #2436
Comments
Thank you for logging this issue. Another suggestion / possible solution might be to introduce a "common" library folder for plugins which are loaded by the parent classloader. This would then prevent that plugins could cause compatibility issues when shipping outdated / incompatible libraries. |
In #2280 we changed the plugin loader so that all plugins share one class loader and they can see each other. (needed for plugin inder-dependencies) This is problematic when different plugins have conflicting dependencies. (see #2436) With this change, every plugin gets its own class loader by default so we can avoid dependency clashes. Plugins which depend on other plugins can request a shared class loader via a graylog-plugin.properties file. Fixes #2436
In #2280 we changed the plugin loader so that all plugins share one class loader and they can see each other. (needed for plugin inter-dependencies) This is problematic when different plugins have conflicting dependencies. (see #2436) With this change, every plugin gets its own class loader by default so we can avoid dependency clashes. Plugins which depend on other plugins can request a shared class loader via a graylog-plugin.properties file. Fixes #2436
In #2280 we changed the plugin loader so that all plugins share one class loader and they can see each other. (needed for plugin inter-dependencies) This is problematic when different plugins have conflicting dependencies. (see #2436) With this change, every plugin gets its own class loader by default so we can avoid dependency clashes. Plugins which depend on other plugins can request a shared class loader via a graylog-plugin.properties file. Fixes #2436
* Make it possible for plugins to request a shared class loader In #2280 we changed the plugin loader so that all plugins share one class loader and they can see each other. (needed for plugin inter-dependencies) This is problematic when different plugins have conflicting dependencies. (see #2436) With this change, every plugin gets its own class loader by default so we can avoid dependency clashes. Plugins which depend on other plugins can request a shared class loader via a graylog-plugin.properties file. Fixes #2436 * Adjust log messages in PluginLoader * Move properties file into a subdirectory to avoid clashes The path to the properties file is stored in the "Graylog-Plugin-Properties-Path" attribute of the JAR manifest. * Only create shared class loader if any plugin requests to be shared
@magicdude4eva Could you see if this build fixes the issues you have been seeing? A recent tarball from http://packages.graylog2.org/_/snapshots?q=2.1.0 should be enough to test. Please recompile against that version, and then try to load your plugin. Only plugins that requested a shared classloader will be able to see each other, all other plugins should be isolated and only see the server and its dependencies. I think that will solve your pain :) |
Sounds great. I will not have time to recompile/test within the next 2 weeks (holidays) - I hope that when I am back there will be an alpha/beta release where I can just upgrade Graylog and verify? |
@magicdude4eva I've just tested your plugin on current master with the current Graylog server master and everything works as expected. |
Great news @kroepke - thanks for taking the time and effort to test it on master and providing feedback here. |
Sorry to rain on the parade guys, Using Graylog 2.1.1 with graylog-plugin-jira-1.0.8.jar and the problem is still occurring. Do we need a recompiled graylog-plugin-jira jar? |
@123dev Yes. Please file a bug report in the repository for the JIRA plugin. |
I don't think this is JIRA plugin issue. I am running latest version of Graylog with my current version of JIRA plugin and it works perfectly fine. @123dev log an issue in the JIRA plugin repository with full stack trace/log of Graylog. |
Thanks Gerd and Jochen,
|
@magicdude4eva Where exactly did you get this file from? |
@joschi the initial issue was raised by me as the change to the classloader visibility in Graylog 2.0 introduced conflicting dependencies (i.e. another plugin bootstrapped an older version of HTTPClient causing my plugin to fail). The classloader issue was fixed in 2.1.0. I am currently running Graylog 2.1.1+01d50e5 (installed via CentOS repo) and do not have the issue. @123dev please have a look at #2280 (comment) - if your error is the same, then it is a classloader issue. In this case confirm what version of Graylog server you are using. I am also not sure why your log-file looks like this. Shouldn't it be server.log? A workaround is to remove the conflicting plugin (in my case under Graylog 2.0.0 it was the map-widget plugin) if you are not able to upgrade to a more recent version of Graylog server. There is unfortunately no way that I can patch/fix my plugin, as I require that specific version of HTTPClient, but as @kroepke said, this has been fixed and it also works in my installation. I do not run a Graylog server cluster, but I doubt that clustering would affect the classloader for plugins. |
@joschi the files are under here's the full list
@magicdude4eva I'm using the latest Graylog version Thanks |
@123dev These log files are written by What problem are you having specifically with the JIRA alarm callback plugin? Which error messages do you get? |
@123dev Could you please do a ls on the plugins directory as well as show us a stack-trace on the JIRA plugin. Perhaps a gist of a clean log-file after restart up to the point where the error occurs would be the best option. |
@joschi
Besides I couldn't find any viewer that would display one of those binary files so that I can extract the log for magicdude4eva . The problem I'm encountering is that the plugin gets triggered, but the message is not attached. This doesn't always happen, but does happen every now and then. Did I comment in the wrong thread? @magicdude4eva
How do I get stack trace of Jira plugin? The problem hasn't happened again since I brought this up two days ago. Thanks guys. |
Continuing the discussion from #2280 (comment)
Since 2.0.2 Graylog uses a single classloader to load all plugins. This is necessary so that plugins can extend/use other plugins.
The downside of this setup is that conflicting dependency versions now clash, even if a given plugin does not need access to other plugins.
One possible solution could be to let plugins declare their classloader isolation preference, with defaulting to "fully isolated".
Plugins which do need access to other plugins could then declare that preference and thus extend them.
This issue exists so we can discuss possible approaches and make a decision how to proceed (or to come up with workarounds for affected plugin authors)
The text was updated successfully, but these errors were encountered: