Theres a thread about it in Stackoverflow. http://stackoverflow.com/questions/5504555/guice-is-it-possible-to-inject-modules
Den lørdag den 8. marts 2014 17.11.57 UTC+1 skrev Nate Bauernfeind: > > It does depend on how you're doing your listener pattern, but Guava's > EventBus might be a nice alternative, like I explained in an earlier email. > > I think Sam was just pointing out that it seems like you're using Guice in > an unintended way. Which can decrease the satisfaction of your particular > experience. > > Which, of course is a shame, because Guice has been an amazing experience > for me, and I won't do any project without it. > > It should technically be possible to have a two stage dependency injection > setup. I've personally toyed with the idea as a way to decouple > configuration from the application (before I started using dropwizard I > used multiple json files that would auto inject @Named strings). It should > work in your case as well if you name your collections and inject them into > your modules. > > So the idea is that the first injector is created to instantiate all > modules, so you would need very few super modules that binds each of your > original modules. You will likely want to use multibinder to register each > module so that you can pull them directly off of this initial injector to > construct the second phase injector. > > It should work and may help with the problem you've found yourself in. > > If you feel like you can share a handful of module source files with me, > out of thread, I'd be happy to see if there are even better and more > concrete suggestions I can give you. > > Nate > On Mar 8, 2014 9:02 AM, "Mikkel Petersen" <mlp...@gmail.com <javascript:>> > wrote: > >> >> Well multiibindings solves, in a way, the listener problem. Because it >> works on sets. But it doesnt solve if I wanted to access other objects from >> other modules. >> If you could care to explain to me why this is "wrong" without saying >> "its just wrong" I'm all ears. >> You might as well say that using a injection framework is wrong because >> injection is a sign that the logic in your application is wrong. >> I'm not convinced at all that my clam is not legitimate but we can >> disagree on that, no problem. I'll simply note that at this point, Guice >> can't handle this problem. >> Den lørdag den 8. marts 2014 15.56.16 UTC+1 skrev Sam Berlin: >>> >>> I suggested going specifically to StackOverflow, which is a website >>> devoted to programming questions/answers. >>> >>> Additionally, I suggested a solution of Multibindings, which AFAICT is >>> specifically for the problem you outlined. >>> >>> If you have further problems, I'm not sure I can help much more, though >>> others on this list may be able to. >>> >>> sam >>> >>> >>> On Sat, Mar 8, 2014 at 9:54 AM, Mikkel Petersen <mlp...@gmail.com>wrote: >>> >>>> >>>> Btw, Multibindings doesnt solve this..but I'm glad that you told me I >>>> do things wrong, without telling me why, and without providing an >>>> alternative solution. Did you even look at the sample ? >>>> Den lørdag den 8. marts 2014 15.51.21 UTC+1 skrev Mikkel Petersen: >>>> >>>>> Are you suggestion I should google around and ask ? thanks, would have >>>>> never thought about that.. >>>>> >>>>> Den lørdag den 8. marts 2014 03.45.59 UTC+1 skrev Sam Berlin: >>>>>> >>>>>> I hate to break it to you, but it increasingly looks like you're >>>>>> making this much harder for yourself, using the framework in a way it's >>>>>> not >>>>>> intended. >>>>>> >>>>>> For this particular problem (adding things to a shared pool), there's >>>>>> an extension called Multibinder: http://code.google.com/p/googl >>>>>> e-guice/wiki/Multibindings . >>>>>> >>>>>> For other issues, you may want to consider asking for specific >>>>>> guidance and help in StackOverflow (or searching for existing >>>>>> questions/answers). I suspect you'll find that things will become a lot >>>>>> simpler. >>>>>> >>>>>> sam >>>>>> On Mar 7, 2014 7:33 PM, "Mikkel Petersen" <mlp...@gmail.com> wrote: >>>>>> >>>>>>> It's hard for me to describe the entire problem..I was really just >>>>>>> looking for a solution to this, now it has turned into something else. >>>>>>> But >>>>>>> fine, I'll try to explain my point further. >>>>>>> >>>>>>> Lets say its not fully possible to populate an object just from >>>>>>> Module, that other modules should have access to this object as well in >>>>>>> order for it to be fully ready for use. >>>>>>> >>>>>>> For example, we have an object NameList >>>>>>> >>>>>>> Module A { >>>>>>> configure() { >>>>>>> nameList = new NameList() >>>>>>> bind(NameList.class).toInstance(nameList) >>>>>>> name = new Name("peter") >>>>>>> requestInjection(name) >>>>>>> nameList.add(name) >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> Module B { >>>>>>> Name name = new Name("James") >>>>>>> requestInjection(name) >>>>>>> nameList.addName(name) >>>>>>> >>>>>>> } >>>>>>> >>>>>>> Module B binds a new name, injects it, and adds it to the NameLIst. >>>>>>> But the namelist was created and bound in module A !! How will it get a >>>>>>> reference to NameList ? >>>>>>> We could do something like this >>>>>>> >>>>>>> GuiceStatics { >>>>>>> public static NameList nameList >>>>>>> } >>>>>>> And access it from here. Or make a singleton factory or whatever. >>>>>>> But why ? this is what Guice helps us to avoid ! >>>>>>> >>>>>>> Point is, the entire module section of any application can grow into >>>>>>> something huge itself. And because of that, it needs dependency >>>>>>> injection >>>>>>> itself. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Den lørdag den 8. marts 2014 01.22.37 UTC+1 skrev Sam Berlin: >>>>>>>> >>>>>>>> I don't understand why your modules need things injected. The >>>>>>>> point of modules is to set up rules saying "this is bound to that" and >>>>>>>> "when someone wants this, give them that". It does not require >>>>>>>> knowing the >>>>>>>> interrelationships of each object. I highly suspect there's something >>>>>>>> fundamentally wrong with your setup, but it's hard to say for certain >>>>>>>> without knowing what you're doing. >>>>>>>> >>>>>>>> sam >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Mar 7, 2014 at 7:18 PM, Mikkel Petersen >>>>>>>> <mlp...@gmail.com>wrote: >>>>>>>> >>>>>>>>> I have already optimized each and every module..I have spent years >>>>>>>>> doing that, really. But they still run into the exact same problem >>>>>>>>> that >>>>>>>>> Guice was supposed to solve: how do we get object A to object B. >>>>>>>>> With hundreds of modules, that problem will occur over and >>>>>>>>> over..For example, I have a list of Listeners in Module A. Module A >>>>>>>>> binds >>>>>>>>> them, plus add some listener code to the list. Module XYZ23B now >>>>>>>>> wants to >>>>>>>>> add a listener to this list as well. How ? Only solution right now is >>>>>>>>> to >>>>>>>>> have a class that references this list public and statically. Now, >>>>>>>>> you >>>>>>>>> could say, my logic is wrong. All logic concerned this listener list >>>>>>>>> should >>>>>>>>> be in one module..but perhaps the two do not have much in common >>>>>>>>> logic wise >>>>>>>>> than this object. >>>>>>>>> >>>>>>>>> Den lørdag den 8. marts 2014 01.08.14 UTC+1 skrev Nate >>>>>>>>> Bauernfeind: >>>>>>>>>> >>>>>>>>>> I can't say that I've ever dealt with an experience of having >>>>>>>>>> 100+ unique modules (now if you want to talk about 100+ child >>>>>>>>>> injectors >>>>>>>>>> created from different instances of the same module (i.e. as a >>>>>>>>>> template)... >>>>>>>>>> now that I've done). I think my largest experience has sliced things >>>>>>>>>> up >>>>>>>>>> into maybe 15 modules; which is still quite a handful to manage. >>>>>>>>>> >>>>>>>>>> The biggest thing that I did that helped managed dependency >>>>>>>>>> relationships across modules was to prefer PrivateModules over >>>>>>>>>> completely >>>>>>>>>> public AbstractModules. It made me really think about what each >>>>>>>>>> module was >>>>>>>>>> being used for and what it exposed for use with the rest of the >>>>>>>>>> application. For example, I don't mind creating a different >>>>>>>>>> ExecutorService >>>>>>>>>> that might be used in an entire sub-graph that is not shared across >>>>>>>>>> all of >>>>>>>>>> my modules. In fact, limiting how portions of your application can >>>>>>>>>> interact, or interfere, with each other can dramatically improve >>>>>>>>>> your >>>>>>>>>> experience when debugging or fine-tuning certain things. >>>>>>>>>> >>>>>>>>>> Perhaps, migrating and merging some of your modules to each have >>>>>>>>>> a specific purpose might bring things back to being manageable and >>>>>>>>>> meaningful for you. >>>>>>>>>> >>>>>>>>>> Additionally, I've had some experience here and there using >>>>>>>>>> Guava's EventBus to further decouple sub-systems by instead >>>>>>>>>> communicating >>>>>>>>>> with messages. For example instead of injecting the TwitterService >>>>>>>>>> and have >>>>>>>>>> every listener register itself as a listener, I instead can use the >>>>>>>>>> EventBus to subscribe to all messages of a type "TwitterEvent" and >>>>>>>>>> then the >>>>>>>>>> messages get to the right places behind the scenes on my behalf (you >>>>>>>>>> only >>>>>>>>>> need to add an @Subscribe assuming you let guice register your >>>>>>>>>> objects). >>>>>>>>>> This works well for data that flows as opposed to data that you need >>>>>>>>>> to >>>>>>>>>> pass back an answer (though I've tried this too by passing a >>>>>>>>>> settable >>>>>>>>>> Future as a means of a lightweight callback -- but I wasn't >>>>>>>>>> extremely >>>>>>>>>> satisfied, nor unsatisfied, with the result). The applications that >>>>>>>>>> I have >>>>>>>>>> that use an event bus can typically remove a guice module from the >>>>>>>>>> list >>>>>>>>>> that gets passed into the injector and everything will still start >>>>>>>>>> up and >>>>>>>>>> run appropriately -- just no one will get any TwitterEvents if that >>>>>>>>>> module >>>>>>>>>> was removed. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Fri, Mar 7, 2014 at 5:16 PM, Mikkel Petersen <mlp...@gmail.com >>>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>>> Thank you all for your responses ! >>>>>>>>>>> >>>>>>>>>>> Problem is, my application has grown to the point that even the >>>>>>>>>>> modules themselves have becoming an application. >>>>>>>>>>> >>>>>>>>>>> So there are many objects created in different modules, needed >>>>>>>>>>> by others... >>>>>>>>>>> >>>>>>>>>>> What I really need is to be able to inject dependencies into >>>>>>>>>>> module. >>>>>>>>>>> >>>>>>>>>>> The ideal solution would be >>>>>>>>>>> TestModule extends Module { >>>>>>>>>>> Inject SomeObjectCreatedInAFarWayModule someObject; >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> But that is not possible, so because of that I took a look at >>>>>>>>>>> providers, which allow dependencies to be injected into modules. >>>>>>>>>>> My application has at least 100 modules by now, and growing. >>>>>>>>>>> So far I have used static public objects, but as everyone knows, >>>>>>>>>>> that is bad practice. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Den lørdag den 8. marts 2014 00.07.22 UTC+1 skrev Nate >>>>>>>>>>> Bauernfeind: >>>>>>>>>>>> >>>>>>>>>>>> @Provides are typically when you need to inject an instance of >>>>>>>>>>>> some library out of your control that doesn't have any guice >>>>>>>>>>>> bindings. I >>>>>>>>>>>> try to avoid using providers for any other use case. In your >>>>>>>>>>>> specific >>>>>>>>>>>> example, I would do what Sam suggested and just simply inject the >>>>>>>>>>>> Settings >>>>>>>>>>>> object. >>>>>>>>>>>> >>>>>>>>>>>> I use dropwizard a lot and typically finding myself creating >>>>>>>>>>>> hierarchical configuration objects, and passing the >>>>>>>>>>>> sub-configuration >>>>>>>>>>>> object to a specific module. For example, >>>>>>>>>>>> >>>>>>>>>>>> class ApplicationConfiguration { >>>>>>>>>>>> public DatabaseConfiguration data; >>>>>>>>>>>> public TwitterConfiguration twitter; >>>>>>>>>>>> ... >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> And then they map one-to-one to a top-level PrivateModule which >>>>>>>>>>>> accepts the sub-configuration object as part of its constructor. >>>>>>>>>>>> Then I can >>>>>>>>>>>> easily either inject the configuration class privately for that >>>>>>>>>>>> sub-portion >>>>>>>>>>>> of my application, or do whatever I need to with it (like >>>>>>>>>>>> configure an http >>>>>>>>>>>> client in a @Provides method). >>>>>>>>>>>> >>>>>>>>>>>> Happy Guicing! >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Fri, Mar 7, 2014 at 5:00 PM, Mikkel Petersen < >>>>>>>>>>>> mlp...@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Thanks for your response. >>>>>>>>>>>>> >>>>>>>>>>>>> It's seems overly complicated and I must admit, I don't >>>>>>>>>>>>> understand it fully..though it properly works..I fail to see the >>>>>>>>>>>>> usage of >>>>>>>>>>>>> @Provides methods if the object provided doesn't have the object >>>>>>>>>>>>> graph >>>>>>>>>>>>> injected. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Den fredag den 7. marts 2014 23.54.17 UTC+1 skrev Nate >>>>>>>>>>>>> Bauernfeind: >>>>>>>>>>>>>> >>>>>>>>>>>>>> It's a bit more work, but you could consider using assisted >>>>>>>>>>>>>> injection for this kind of use-case. My typical pattern looks >>>>>>>>>>>>>> like this: >>>>>>>>>>>>>> >>>>>>>>>>>>>> public class Example { >>>>>>>>>>>>>> @Inject >>>>>>>>>>>>>> public Example(@Assisted("host") String host >>>>>>>>>>>>>> HttpClient httpClient, >>>>>>>>>>>>>> ...) { >>>>>>>>>>>>>> ... >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> /** This class is a Guice Assisted-Inject Factory. */ >>>>>>>>>>>>>> public static interface Factory { >>>>>>>>>>>>>> Example newExample(@Assisted("host") String host); >>>>>>>>>>>>>> } >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> ... >>>>>>>>>>>>>> >>>>>>>>>>>>>> public class ExampleModule { >>>>>>>>>>>>>> void configure() { >>>>>>>>>>>>>> bindFactory(Example.class, Example.Factory.class); >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> protected <T, F> void bindFactory(Class<T> klass, Class<F> >>>>>>>>>>>>>> factoryKlass) { >>>>>>>>>>>>>> bindFactory(klass, klass, factoryKlass); >>>>>>>>>>>>>> } >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> And then you can still use a provider method (if you prefer!) >>>>>>>>>>>>>> and then you inject the factory and the settings. >>>>>>>>>>>>>> >>>>>>>>>>>>>> @Provides >>>>>>>>>>>>>> public Example someExample(Example.Factory factory, Settings >>>>>>>>>>>>>> settings) { >>>>>>>>>>>>>> return factory.newExample(settings.getHost()); >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hope that helps! I use this pattern a lot, but not often >>>>>>>>>>>>>> mixed with a Provider -- usually I have a class that manages the >>>>>>>>>>>>>> multiple >>>>>>>>>>>>>> instances key'ed by some name (like client or user). >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Fri, Mar 7, 2014 at 4:44 PM, Mikkel Petersen < >>>>>>>>>>>>>> mlp...@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Because I want to receive other bindings: >>>>>>>>>>>>>>> public Service someService(@Inject Settings settings) { >>>>>>>>>>>>>>> SomeService s = new SomeService(settings.getHost()) >>>>>>>>>>>>>>> inj.injectMembers(s) >>>>>>>>>>>>>>> return s >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Den fredag den 7. marts 2014 23.32.42 UTC+1 skrev Nate >>>>>>>>>>>>>>> Bauernfeind: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> What about your use case prevents you from using a normal >>>>>>>>>>>>>>>> .to binding? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> bind(SomeService.class).to(SomeService.class) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Nate >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Fri, Mar 7, 2014 at 4:13 PM, Mikkel Petersen < >>>>>>>>>>>>>>>> mlp...@gmail.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hello all >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I have a slight problem with guice injection when using a >>>>>>>>>>>>>>>>> method annotated with @Provides >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> example : >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> @Provides >>>>>>>>>>>>>>>>> public Service someService() { >>>>>>>>>>>>>>>>> return new SomeService() >>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I would like to get the current context injected in >>>>>>>>>>>>>>>>> SomeService..I don't understand why Guice doesn't do that >>>>>>>>>>>>>>>>> automatically, >>>>>>>>>>>>>>>>> any particular reason for that ? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I know I could do something like this (it works): >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> @Provides >>>>>>>>>>>>>>>>> public Service someService(@Inject Injector inj) { >>>>>>>>>>>>>>>>> SomeService s = new SomeService() >>>>>>>>>>>>>>>>> inj.injectMembers(s) >>>>>>>>>>>>>>>>> return s >>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> But there must be a simpler way. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Ps, another question, how to add syntax highlighting ? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> 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 google-guice...@googlegroups.com >>>>>>>>>>>>>>>>> . >>>>>>>>>>>>>>>>> To post to this group, send email to >>>>>>>>>>>>>>>>> google...@googlegroups.com. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Visit this group at http://groups.google.com/group >>>>>>>>>>>>>>>>> /google-guice. >>>>>>>>>>>>>>>>> For more options, visit https://groups.google.com/d/optout >>>>>>>>>>>>>>>>> . >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> 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 google-guice...@googlegroups.com. >>>>>>>>>>>>>>> To post to this group, send email to >>>>>>>>>>>>>>> google...@googlegroups.com. >>>>>>>>>>>>>>> Visit this group at http://groups.google.com/group >>>>>>>>>>>>>>> /google-guice. >>>>>>>>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>> 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 google-guice...@googlegroups.com. >>>>>>>>>>>>> To post to this group, send email to >>>>>>>>>>>>> google...@googlegroups.com. >>>>>>>>>>>>> Visit this group at http://groups.google.com/group >>>>>>>>>>>>> /google-guice. >>>>>>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>> 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 google-guice...@googlegroups.com. >>>>>>>>>>> To post to this group, send email to google...@googlegroups.com. >>>>>>>>>>> Visit this group at http://groups.google.com/group/google-guice. >>>>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>> 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 google-guice...@googlegroups.com. >>>>>>>>> To post to this group, send email to google...@googlegroups.com. >>>>>>>>> Visit this group at http://groups.google.com/group/google-guice. >>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>> 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 google-guice...@googlegroups.com. >>>>>>> To post to this group, send email to google...@googlegroups.com. >>>>>>> Visit this group at http://groups.google.com/group/google-guice. >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> -- >>>> 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 google-guice...@googlegroups.com. >>>> To post to this group, send email to google...@googlegroups.com. >>>> Visit this group at http://groups.google.com/group/google-guice. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >> 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 google-guice...@googlegroups.com <javascript:>. >> To post to this group, send email to google...@googlegroups.com<javascript:> >> . >> Visit this group at http://groups.google.com/group/google-guice. >> For more options, visit https://groups.google.com/d/optout. >> > -- 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 google-guice+unsubscr...@googlegroups.com. To post to this group, send email to google-guice@googlegroups.com. Visit this group at http://groups.google.com/group/google-guice. For more options, visit https://groups.google.com/d/optout.
