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

    caseif

    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

    ChipDev

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

    xTigerRebornx

    ShadyPotato https://github.com/Bukkit/Bukkit/bl...g/bukkit/plugin/SimplePluginManager.java#L491
    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

    fireblast709

    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

    xTrollxDudex

    ShadyPotato
    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

    caseif

    ChipDev xTigerRebornx fireblast709 xTrollxDudex

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

    Code:java
    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

    ChipDev

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

    caseif

    Yep, forgot about that. :p
     
  9. Offline

    Skye

    ShadyPotato

    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

    caseif

    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