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" <[email protected]> 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 <[email protected]> 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 <[email protected]>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 <[email protected]>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 >>>>>>>> <[email protected]>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 <[email protected] >>>>>>>>>> > 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 [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/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 [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/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 [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/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 [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/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 [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/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 [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/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 [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/d/optout.
