Thanks for the answer. I will try to refactor the code a bit (in a proper helper Module, rather than just a test class) to support registering with different scopes.
The next step is to fix so that all classes subclassing the given class registered, should be added as listeners to the newly created ListenerDispatcher. This should be pretty straight forward. Just add a TypeListener for the class, and use the injector to get the ListenerDispatcher and do an addListener(). I would have to force a injector.getInstance() for the TypeListener to get triggered tho, as most bindings are lazy. The only eager one is the eager singleton? I wouldn't want to force my listening classes to be singletons tho. Any thoughts about that? On Mon, Nov 15, 2010 at 5:31 AM, Colin Decker <[email protected]> wrote: > That's approximately what I'd do, except I'd pull the TypeLiteral creation > out into another method that returns a TypeLiteral<ListenerDispatcher<T>> > (by casting). I would also just use a Provider that calls > ListenerDispatcher.create and let singleton scope take care of the single > instance. > > Colin > > > 2010/11/14 Christopher Östlund <[email protected]> > > I came up with the solution: >> >> http://pastie.org/private/upjgliufrvrknv4bpzbhw >> >> <http://pastie.org/private/upjgliufrvrknv4bpzbhw>Maybe it can be done a >> bit less verbose ^^ >> >> /C >> >> 2010/11/15 Christopher Östlund <[email protected]> >> >> Thanks for the answers! >>> >>> I think I was a bit unclear on what I was searching for. I think it will >>> be a bit easier if I split the tasks at hand. >>> >>> Is there a way to programatically bind this: >>> >>> @Provides >>> @Singleton >>> public ListenerDispatcher<ZoneActivationListener> >>> getZoneActivationListenerDispatcher() { >>> return ListenerDispatcher.create(ZoneActivationListener.class); >>> } >>> >>> Byt only specifying ZoneActionvationListener.class? I would somehow need >>> to create a Key for ListenerDispatcher<ZoneActiovationListener> to match the >>> result of ListenerDispatcher.create(ZoneActivationListener.class); >>> >>> >>> Thanks! >>> >>> On Sat, Nov 13, 2010 at 10:52 AM, Jean-Francois Poilpret < >>> [email protected]> wrote: >>> >>>> If you need an events dispatching system, you may want to take a look at >>>> guts-events (http://kenai.com/projects/guts) which is an Event Bus >>>> system based on Guice. >>>> Or you may take a look at guts-events and get some inspiration from >>>> there and adapt it to your own system ;-) >>>> >>>> Jean-Francois >>>> >>>> >>>> On 12-11-2010 23:14, [email protected] wrote: >>>> >>>>> Hello list, >>>>> >>>>> Inspired by the neat configuration Module for guice persist, I decided >>>>> to make something similar for a small subpart of my project. I'm not >>>>> fully sure how to create it though. >>>>> >>>>> I want to create a module which sets up the relationship between >>>>> listeners and dispatchers in an event system. The event system is >>>>> based on a class called ListenerDispatcher<T> [1]. I want the module >>>>> to work something like this: >>>>> >>>>> protected void configureEvents() { >>>>> connect(ListeningInterface.class, >>>>> ClassImplementingListeningInterface.class); >>>>> // .... and so on >>>>> } >>>>> >>>>> protected void configure() { >>>>> configureEvents(); >>>>> } >>>>> >>>>> What I want that line to do is: >>>>> >>>>> ListenerDispatcher<ListeningInterface> listenerDispatcher = >>>>> ListenerDispatcher.create(ListeningInterface.class); >>>>> listenerDispatcher.addListener(classImplementingListeningInterface); >>>>> >>>>> Initially I wouldn't need to be able to configure the scope of the >>>>> binding. I just want to reduce the boiler plate to that single line >>>>> (compared to a lot of configuration atm). My initial thoughts is that >>>>> I store all the connect bindings in a map or similar until the >>>>> configure() method of AbstractModule is run. In configure I bind/ >>>>> create all the ListenerDispatchers. So far it's fine, I'm not just >>>>> sure how to runt the addListener part. >>>>> >>>>> Thanks for any pointers or help! >>>>> >>>>> [1] http://pastie.org/private/e20zdyb9nwbmjgq9vgkjhw >>>>> >>>>> >>>>> >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "google-guice" group. >>>> To post to this group, send email to [email protected]. >>>> To unsubscribe from this group, send email to >>>> [email protected]<google-guice%[email protected]> >>>> . >>>> For more options, visit this group at >>>> http://groups.google.com/group/google-guice?hl=en. >>>> >>>> >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "google-guice" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]<google-guice%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/google-guice?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "google-guice" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<google-guice%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-guice?hl=en. > -- You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-guice?hl=en.
