Solved Control which plugins receive a called event

Discussion in 'Plugin Development' started by caseif, Jun 27, 2014.

Thread Status:
Not open for further replies.
  1. Offline


    I recently discovered/realized a major flaw in a library of mine: plugins listening to its custom events will receive events regarding every plugin hooking it, but each event can only apply to one plugin. If a developer doesn't realize or consider this, they'll end up acting upon events regardless of whether it concerns their plugin or not, and while this will work in an isolated scenario, it causes severe problems when run in an environment with more than one hooking plugin. I need a way to control which plugins receive the library's events, or at least a way to work around it. I feel like there's an obvious solution, but it's nearly 3 AM, so I'm not really thinking too clearly. Anyway, some help on this stupid, stupid issue would be greatly appreciated. :)
  2. Offline


    I don't think I'm right...
    But can you check if the 'Receiving' Plugin has the correct name and continue? :confused:
  3. Offline


    In the firing of the events, it calls RegisteredListener#callEvent(). Perhaps you could find a way of overriding that method (as the RegisteredListener also contains the Plugin it was registered from), allowing you control over the listeners of each event. May involve messing with the HandlerList class and its methods for registering the listener as well.

    Or I could just be overthinking this :p

    May cause problems with servers that have plugins interfering with the PluginManager, be sure to post your results on this, I am interested.
  4. Offline


    ShadyPotato HandlerList, which you need to provide in the custom Event, has an array RegisteredListener[], and each of those has a Plugin instance. Instead of using Bukkit.getPluginManager().callEvent(), call RegisteredListener#callEvent(Event) yourself on the RegisteredListener you want to fire it for
  5. Offline


    Play around with the HandlerList's listeners

    Edit: Dangit, double ninja'd while getting distracted on the event registration part of PluginManager :/
    Konkz likes this.
  6. Offline


    ChipDev xTigerRebornx fireblast709 xTrollxDudex

    Thanks for the advice. Here's the method I ended up writing:

    1. public static void callEvent(MGLibEvent event){
    2. HandlerList hl = event.getHandlers();
    3. for (RegisteredListener rl : hl.getRegisteredListeners())
    4. if (rl.getPlugin().getName().equals(event.getPlugin())){
    5. try {
    6. rl.callEvent(event);
    7. }
    8. catch (EventException ex){
    9. ex.printStackTrace();
    10. }
    11. }
    12. }

    Where of course MGLibEvent is the superclass for all custom events. Simple enough, but I couldn't seem to come up with it on my own. :p

    I haven't tested it yet, but I believe it should work as expected.
    ChipDev likes this.
  7. Offline


    I think that will work; :D
    If it does...
    Forum forum = Chip.getCurrentForum();
  8. Offline


    Yep, forgot about that. :p
  9. Offline



    I know this is solved, but you guys are using an overly complex solution. Situations like this are for which Cancellable is used. Plugin authors looking to provide an API for other plugin makers should make their methods only fire if their custom events are not cancelled. Developers should cancel events they don't want passed to the hooked plugin.
  10. Offline

    1Rogue Retired Staff

    Not exactly true pertaining to this situation

    Note that you're comparing the plugin's name to the plugin
  11. Offline


    That's not quite what I want to do. I want to control which plugins receive an event so that only one (the one it pertains to) is able to act upon it, rather than make it so no plugins receive it.

    So it would seem, but MGLibEvent#getPlugin() actually returns a string. Some of the library's methods are a bit weird like that, but sadly, refactoring isn't really an option.
Thread Status:
Not open for further replies.

Share This Page