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" <[email protected] <javascript:>> > 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] <javascript:>. >> To post to this group, send email to [email protected]<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 [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.
