Hi. In the "Registry" pattern it is not necessary to inject the registry in every registered object. It is possible to bind each "ConfigurationItem" to a unique Key=(Type, UniqueAnnotation) and then look in the injector for all bindings to Type.
Here is an example: https://github.com/paweld2/gwtCaiman/tree/master/gwtCaiman/src/main/java/net/customware/gwt/dispatch/server/support In the method ActionHandlerModule.bindHandler, You create unique bindings for each call to this method: bindHandler( Action1.class , ActionHandler<Action1.class,Result1.class ) bindHandler( Action2.class , ActionHandler<Action2.class,Result2.class ) ..... this creates unique bindings keys of the type ActionHandlerMap. Then in the class ActionHandlerLinker you inject statically the injector and the registry, and make the registration: List<Binding<ActionHandlerMap>> bindings = injector.findBindingsByType( TypeLiteral.get( ActionHandlerMap.class ) ); ... for ( Binding<ActionHandlerMap> binding : bindings ) { Class<? extends ActionHandler<?, ?>> handlerClass = binding.getProvider().get() .getActionHandlerClass(); ActionHandler<?, ?> handler = injector.getInstance( handlerClass ); instanceRegistry.addHandler( handler ); } bindings have all the registered "ConfigurationItems" If You look the the multibinding extension, it make something really similar but with additional isolation level of unique keys for each registered map/set. Regards. Pawel Cesar Sanjuan Szklarz. On Sat, Nov 30, 2013 at 5:03 AM, Tim Boudreau <[email protected]> wrote: > A thing to keep in mind is dependency injection != service discovery. > Dependency injection = an object knows what it needs but doesn't want to > be responsible for making it. Service discovery = an object doesn't know > what it needs and may not have been compiled with everything it needs. > > Does the thing creating the database know about the things that want to > add configuration? Or is it something where the thing that sets up the > database is a sort of framework, and it needs to do some sort of lookup to > find the things that want to contribute? > > If the thing that creates the database *does* know about the things that > would add configuration, then the decoupling you're trying to achieve is > actually an illusion, so just initialize them all and pass them in and > don't worry about it. > > If on the other hand, the framework piece doesn't know about it, then you > have a service discovery problem - you need a way to look things up. > > I've used two different patterns for that with Guice. The first is > actually not Guice related - it's using the JDK's ServiceLoader (in this > case, via NetBeans Lookup api, which has a handy @ServiceProvider > annotation for registering services ServiceLoader can see). Here's an > example - in this case I'm binding Jackson's ObjectMapper for JSON > processing, and I want anything on the classpath that wants to configure > JSON serialization to have a chance to: > > https://github.com/timboudreau/giulius-web/blob/master/jackson/src/main/java/com/mastfrog/jackson/JacksonModule.java > > An alternative way that is more Guice-y, but which I like less for reasons > I'll detail is where you have a "Registry" singleton, which objects can > register themselves with; then you bind the things that should contribute > some configuration as eager singletons, so that when you ask the contents > of the registry, you get everything that was bound that way. Here's an > example of that - in this case, I want to register things that intercept > the creation of MongoDB databases and collections (in case they want to > create indexes or set up some default contents): > > https://github.com/timboudreau/acteur/blob/master/acteur-mongo/src/main/java/com/mastfrog/acteur/mongo/MongoInitializer.java > > The pros of the latter approach is that you can turn things off by > unbinding them (as opposed to changing the classpath or recompiling the > contributor - although Lookup actually has a way of declaratively removing > services). The cons are that objects which are to be subclassed but > register themselves in some registry in their superclass constructor is an > antipattern - you can end up with weird race conditions where other threads > are banging on your object's methods before its constructor has completed > (you could eliminate the register call in the super constructor, but you'd > have to tell subclassers "BTW, if you don't do this incantation your code > will mysteriously not work", and inevitably someone will have exactly that > problem - not cool). > > Hmm, it now occurs to me that there's probably some clever interception > thing I could have done instead of that registry...nonetheless... > > -Tim > > -- > You received this message because you are subscribed to the Google Groups > "google-guice" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/google-guice. > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "google-guice" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-guice. For more options, visit https://groups.google.com/groups/opt_out.
