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" <mlp2...@gmail.com> 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+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. > -- 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.
