[ERROR] .... Could not pass event ServiceRegisterEvent to dynmap v3.1-beta-2-389
Bluecolty opened this issue ยท 6 comments
I'm not quite sure how to pose this question. I recently updated my Paper server to 1.15.2, along with all of my plugins. I'm now getting this error in the console with the latest Dynmap plugin error.
[ERROR] .... Could not pass event ServiceRegisterEvent to dynmap v3.1-beta-2-389 java.lang.ClassCastException: com.njdaeger.coperms.vault.Permission_CoPerms incompatible with org.bukkit.plugin.RegisteredServiceProvider at org.dynmap.bukkit.permissions.VaultPermissions.onServiceRegister(VaultPermissions.java:52) ~[?:?] at com.destroystokyo.paper.event.executor.asm.generated.GeneratedEventExecutor83.execute(Unknown Source) ~[?:?] at org.bukkit.plugin.EventExecutor.lambda$create$1(EventExecutor.java:69) ~[patched_1.15.2.jar:git-Paper-372] at org.bukkit.plugin.EventExecutor$$Lambda$2796.00000000DC66FA00.execute(Unknown Source) ~[?:?] at co.aikar.timings.TimedEventExecutor.execute(TimedEventExecutor.java:80) ~[patched_1.15.2.jar:git-Paper-372] at org.bukkit.plugin.RegisteredListener.callEvent(RegisteredListener.java:70) ~[patched_1.15.2.jar:git-Paper-372] at org.bukkit.plugin.SimplePluginManager.callEvent(SimplePluginManager.java:607) ~[patched_1.15.2.jar:git-Paper-372] at org.bukkit.plugin.SimpleServicesManager.register(SimpleServicesManager.java:59) ~[patched_1.15.2.jar:git-Paper-372] at com.njdaeger.coperms.CoPerms.onEnable(CoPerms.java:62) ~[?:?] at org.bukkit.plugin.java.JavaPlugin.setEnabled(JavaPlugin.java:263) ~[patched_1.15.2.jar:git-Paper-372] at org.bukkit.plugin.java.JavaPluginLoader.enablePlugin(JavaPluginLoader.java:380) ~[patched_1.15.2.jar:git-Paper-372] at org.bukkit.plugin.SimplePluginManager.enablePlugin(SimplePluginManager.java:483) ~[patched_1.15.2.jar:git-Paper-372] at org.bukkit.craftbukkit.v1_15_R1.CraftServer.enablePlugin(CraftServer.java:472) ~[patched_1.15.2.jar:git-Paper-372] at org.bukkit.craftbukkit.v1_15_R1.CraftServer.enablePlugins(CraftServer.java:386) ~[patched_1.15.2.jar:git-Paper-372] at net.minecraft.server.v1_15_R1.MinecraftServer.a(MinecraftServer.java:488) ~[patched_1.15.2.jar:git-Paper-372] at net.minecraft.server.v1_15_R1.DedicatedServer.init(DedicatedServer.java:298) ~[patched_1.15.2.jar:git-Paper-372] at net.minecraft.server.v1_15_R1.MinecraftServer.run(MinecraftServer.java:908) ~[patched_1.15.2.jar:git-Paper-372]
As far as I know, this error doesn't affect anything, but I'd like to see if there is a possible solution. If you need any more info, just ask! This is my first time posting an issue, so hopefully I've described it enough. Thanks!
I believe this error stems from https://github.com/webbukkit/dynmap/blob/v3.0/spigot/src/main/java/org/dynmap/bukkit/permissions/VaultPermissions.java#L52
That variable should be of type net.milkbowl.vault.permission.Permission
and not org.bukkit.plugin.RegisteredServiceProvider
.
Calling ServiceRegisterEvent#getProvider
is the RegisteredServiceProvider
. Calling RegisteredServiceProvider#getProvider
returns what the provider is providing, which would be the Permission
class.
I can submit a PR later if that change is fine with anyone else, I believe it would be correct if I did it my way.
Feel free to make a PR with this change, mike will review it and assuming it compiles and is compatible with the myriad versions dynmap supports now it will be accepted.
make sure to real the PR guidelines first please
Yep - vault support came in from PR from @zml2008 - I cannot vouch for it, as I don't use Vault personally. I can try the change, but I'm not set up to test it. If you can PR it and check it out, we'll be happy to accept the fix.
ah my bad, sorry about that!
The logic to determine which service should be used uses information from the RegisteredServiceProvider
, so the best fix would imo be to take off one level of getProvider()
, meaning line 52 would become:
RegisteredServiceProvider<Permission> newProvider = (RegisteredServiceProvider<Permission>) event.getProvider();
Unfortunately I don't think there's an automated test for this, and because of Bukkit's generics usage we'll always have to be an unchecked cast. Luckily I doubt this code will have to change much in the future, since that part of bukkit has been quite stable.
Added the change suggested by @zml2008