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 <mlp2...@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/ >>> google-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+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.
