Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Fix plugin inter-dependencies by using one class loader for all plugins #2280
I guess technically we don't need the second classloader and could instead set the parent (i.e. Graylog's) in the URLClassloader as the chaining classloader really delegates to the parent first anyway.
However, if we don't need to touch all of that now I'd prefer not to. But I guess it's simple to test whether it makes a different. I'm unsure what the consequences for any plugin resources are. So far I haven't seen any conflicts, but that doesn't mean there aren't any somewhere.
May 25, 2016
4 checks passed
added a commit
this pull request
May 25, 2016
This is problematic. The
My plugin can now not ship with httpclient as it conflicts with some classes in the map-plugin, but can also not ship without httpclient as
I can now try to "hack" together my plugin to include classes which are missing from the map-plugin as I can not include httpclient or I can ask users to completely remove the map-plugin from the plugins folder and then ship my plugin as before with httpclient and httpmime.
In my case I am using jira-client which uses URIBuilder which is pulled from my bundled version of httpclient, but then references
Alternatively, could the map-widget at least include versions of httpclient which are more up-to-date than 4.0.1?
@magicdude4eva We can update it, but for various reasons we need the plugins to share a classloader.
Can you shade/relocate that specific dependency in your plugin? That should provide a workaround.
I can try shade/relocate and hope that with the various dependencies https://github.com/rcarz/jira-client will still work (which I need for my plugin https://github.com/magicdude4eva/graylog-jira-alarmcallback).
Just to confirm: Was the classloader change for plugins introduced with 2.0.3 (I am currently running 2.0.3 and can not recall to having the issue before).
I think the big problem with one classloader is that any plugin could break anyone else and then it becomes plugin authors responsibility to try and fix a workaround.
If anyone can find a clever workaround for my problem, feel free to assist with the pom (I am honestly struggling with this as I am not very familiar with maven builds - https://github.com/magicdude4eva/graylog-jira-alarmcallback).
For now I will just ask users to delete the map-plugin as I have no time to try and find a work-around for this in the next week or two.
This was changed in 2.0.2 to fix an issue with our commercial plugins.
I realize that a common classloader can pose challenges but the alternatives require immense complexity as well.
Regarding the jira library, the only thing I see that could be problematic is that it uses a really old Jodatime version. It's the same issue with the httpclient being pulled in by the map widget: the old dependency actually comes in transitively which makes it difficult to update it, because upstream, third parties need to update, in this case MaxMind.
I'll start a new issue to track and discuss this.
Thank you @kroepke. One more question before I try another work-around:
When looking at the server log it shows that my "JIRA" plugin is loaded first:
Would my assumption be correct, that since I bundle a newer version of httpclient, that if I just do a "dummy" instantiation of HTTPClient classes in a static initialiser block of my AlarmCallBack-class that this would then trigger the loading of my httpclient classes and then breaking the map-plugin?
The load order is pretty much undefined, so I wouldn't rely on it.
Whether or not the map plugin breaks depends on the binary compatibility of the different versions, that's tricky to say.
I tried for the last 4 hours to work around this issue, but there is no good way solving it without hacking the build and it will be just a matter of time that another user has similar issues.
For me personally it is okay to delete the map-plugin as I don't use it, but I think other users might have similar issues when moving to Graylog 2.0.2/2.0.3.