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" <[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.
