SLF4J class loader conflict
andrewkm opened this issue · 19 comments
https://pastebin.com/raw/iztVVSyp
This is happening on Bungee.
Luckperms 4.2.96
Same thing, this is all started happening ever since dropping in the latest NuVotifier:
https://github.com/parallelblock/NuVotifier
Seems related to #1153 ?
@lucko perhaps also related to:
NuVotifier/NuVotifier#101
We are fixing this on the NuVotifier side since obviously we are loading in unshaded resources. Obviously this happens due to a conflict but no action is required on LuckPerm's side for this particular issue.
LuckPerms is also loading it without relocation - so there's an issue at both ends.
I'd like to try to work out the cause here. It appears to only be an issue with BungeeCord - LP's dynamic loading of SLF4J isn't an issue with NuVotifier on Bukkit, for example.
NuVotifier/NuVotifier#101
Confirmed fixed here @lucko
So if I am interpreting these two code parts correctly:
It looks like Bukkit will try to reuse Classes defined globally previously before it goes to load a class, whereas Bungee will attempt to redefine a class from the Jar before going global. Idk, maybe i'm barking up the wrong tree since I don't understand how LP loads in dependencies (haven't looked at the code whatsoever :P) but this is probably the contributing factor.
Either way, its pretty bad. NuVotifier didn't use any intricate features of slf4j to hit a bad method signature presented by differences between the version bundled and whatever LP decided to pull in (or maybe it was the other way around? who knows...) so thats probably why we didn't see it blow up on Bukkit. I don't know, ClassLoaders are one of those magical things. I wish Bukkit or Bungee supported sideloading shared library jars, but oh well to that I suppose.
It looks like Bukkit will try to reuse Classes defined globally previously before it goes to load a class, whereas Bungee will attempt to redefine a class from the Jar before going global. Idk, maybe i'm barking up the wrong tree since I don't understand how LP loads in dependencies (haven't looked at the code whatsoever :P) but this is probably the contributing factor.
I think you're absolutely right :)
Can this issue cause other problems to?
Bungeetablist is spamming my console with one error https://pastebin.com/kGEYXQm6
Im not running any of does plugins.
My server is not open for public. ill try plugin for plugin.
Oke i can fix my problem myself because of a plugin i forget to remove....
Not using it anymore and didnt set it up.
ReportPlus v6.1.jar
Also fix the console spam i had. So everything is fine.
Only thing i can think of, maybe you didnt set up a plugin?
Link to the plugin that was causing my problems:
https://www.spigotmc.org/resources/reportplus-bungeecord-%E2%98%86-gui-%E2%98%86-discord-%E2%98%86-customizable-%E2%98%86-titles-%E2%98%86-discord-announcements-%E2%98%86-and-more.50455/
@Duqino Could be the same issue, but I'd need to see your full startup log to confirm that.
Here it is. https://pastebin.com/8itknft3
I can't reproduce this using:
- BungeeCord v1356
- LuckPerms 4.2.107
- BTLP 2.8.10-SNAPSHOT
- NuVotifier 2.4.1
https://gist.github.com/lucko/1b29e5e24d5822134f074bfa980c6e5b
Any ideas?
A quick question to shading the org.slf4j package - I'm relocating it via pom relocation in a test version of the Maintenance plugin (mentioned in #1153 (comment) + kennytv/Maintenance#8, though it seemed to be fixed by doing the shading in "Plan", buut to be shure with other plugins I'd want to do it anyways) and it seems to be located where I want it to be... Is there any downside to that / what exactly do you mean by "[...] that we will be getting rid of slf4j. Obviously that's the cop-out solution, but when it comes down to it slf4j can't be relocated easily."@Ichbinjoe ?
Iirc slf4j tries to do reflection on itself. I think I tried doing it for like 5 minutes but then realized the scope at which Tux was using slf4j and the weird hacks he had to do to get it to work, and I just decided to remove the dependency all together.