1

I have been using the pico container in java to do DI for a minecraft plugin framework I designed.

The plugins have event listener methods that are defined in interfaces, one method per interface.

If a particular class wants events when players join and leave the server, it implements the two particular interfaces; in this case IPlayerLoginEvent and IPlayerQuitEvent.

I then have a class in the frameworks which takes each type of event interface as a constructor injected argument.

This container class is tagged with @Listener for the craftbukkit server software to call it.

The wrapper class wraps the data craftbukkit sends in with a framework-specific class, making it possible, at least in theory, to write server-agnostic plugins.

Small example:

The plugin AwesomePlugin has a class PlayerHandler which implements IPlayerLoginEvent and IPlayerQuitEvent. The framework needs then to construct instances of each of the classes "PlayerLogin" and "PlayerQuit", passing in the PlayerHandler as a constructor argument. The PlayerLogin and PlayerQuit instances will in turn be registered with CraftBukkit as event listeners.

The way this is currently implemented using pico, can be seen here:

https://github.com/Runsafe/Framework/blob/master/src/no/runsafe/framework/event/EventEngine.java#L32

That code does look terrible and I have not been able to find a more elegant solution for this scenario, so I now beseech your guidance :)

Morten Nilsen
  • 621
  • 7
  • 18
  • I suggest adding a bit more info on your architecture; kind of hard to follow what's going on without digging deep into your code. – Torious Oct 31 '12 at 12:53

1 Answers1

2

Well, I don't quite understand you question but I can explain some pico events patterns.

First of all, events are container-centric, you don't use pico just to wire things up. Every event consumer is added to the container. Each consumer has to implement at least one method to get event obj. You can have single interface with generic Event class passed, or you can have many interfaces for different event types.

Thus, you have a list of consumers in the container (or several lists for several event types) You can either have the list of consumers injected into some event broadcaster object (obviously done once per container creation, the broadcaster receives the event somehow from somewhere, then just iterates through the list and calls relevant event handler methods) or just make a container custom lifecycle call (can be done anytime and trigger consumers added in runtime, the calling job is done by the container itself)

Sometimes you may even want to create new event-container for each event, adding the event obj and all the relevant consumers.

Waffle framework contains the nicest examples of pico containers juggling, events handling etc.

xeye
  • 1,250
  • 10
  • 15
  • I will read your answer more in depth later, as I didn't immediately follow, but for now, here is some additional information: The CraftBukkit server has a method I call to register event listeners. These need to be tagged with @EventHandler and have some method that takes a specific event type as its argument. I do not want to create event listeners in a plugin that will not be used, thus I wrote the mapping code, which creates the listeners that are needed.. I will return to this thread tomorrow, for now I need sleep.. – Morten Nilsen Oct 31 '12 at 23:23
  • Okay, after thinking about this for a while, I think I understand what you are saying and it sounds like a good system. Unfortunately, it won't fully solve my case.. I do not want every plugin written for the framework to listen for all server events, for performance reasons. If there was some way of registering multiple components implementing an interface, and then get instances of all the implementations of that interface, ignoring the ones with missing dependencies, that would nicely address my issue.. – Morten Nilsen Nov 02 '12 at 14:04
  • What do you mean by 'missing deps'? You can split events flow using different interfaces or just use different methods without any interfaces (reflection based lifecycle, pico feature) or you can have single empty marker interface for event listeners and then pass event using your own reflection-based lookup. Tere're many options actually. – xeye Nov 02 '12 at 20:09
  • I mean, if I register a class that takes something as a constructor argument, but I then do not register something implementing that dependency, I do not want pico tro try initing that class.. it cannot do that.. I have custom event interfaces on my classes, but I need bukkit event handlers to route the events through. However, I do not want to listen for more events than needed. – Morten Nilsen Nov 03 '12 at 01:35
  • Thanks for your input, I have found a better strategy now thanks to it. The code is still on github for anyone curious. – Morten Nilsen Jan 24 '13 at 23:30