search

SpongePowered / Sponge

The SpongeAPI implementation targeting vanilla Minecraft and 3rd party platforms.
MIT License
390 stars 211 forks source link

From API 9, Cannot listen to events from inside isolated classloader -- lookup does not have full privileges #3747

Open A248 opened 2 years ago

A248 commented 2 years ago

Is this request specific to one implementation of Sponge?

No

Sponge Version

spongevanilla-1.18.2-9.0.0-RC1157

What are you requesting?

That plugins may define isolated classloaders and listen to events using @Listener annotations.

Plugins are able to create isolated classloaders. In API 8, a publicly-visible listener may listen to events using @Listener annotations even if the listener class is loaded by the child classloader. Although the listener class is not visible to parent classloaders, @Listener remains a usable means of listening to events.

In API 9 this is no longer possible, due to changes in #3467 . Attempting to register such a listener yields: https://pastebin.com/28NhAuhh

Therefore I'm requesting that this functionality be re-added to API 9.

zml2008 commented 2 years ago

We can probably add a method to the EventManager that takes an explicit Lookup for registration - beyond that interacting with the API outside a sponge-created class loader is at your own risk

A248 commented 2 years ago

That sounds like an acceptable solution. I've created a PR which adds an overloaded EventManager#registerListeners(PluginContainer, Object, Lookup) method. It would be fine if you prefer to rename this method; I'll adjust the PR accordingly if so.

beyond that interacting with the API outside a sponge-created class loader is at your own risk

May I ask you to clarify this statement? It would seem to me that classloader creation is an entirely normal state of affairs. Many plugins load jars dynamically, for various purposes: library loading, addon and extension systems, jar-in-jar packaging all come to mind. If classloader creation is officially deemed an at-risk operation, then all these use-cases become untenable where safety and stability are inviolate.

If you maintain that defining an isolated classloader is "at your own risk," does this imply that plugins lose API guarantees due to creating their own classloaders?