I don't really understand how you aren't able to come up with a static set of singletons that you want to be changing at each type of request.
The solution that you're trying to take sounds like a terribly hard one to maintain. I advise you to look, seriously, into picking an alternative dependency injection pattern. I imagine that you're going to have a hard time debugging issues that arise from unexpected leakages between tasks/injectors. If your application changes state dramatically based on the current task then you may really want to try and structure it that way. You can create a global injector for the infrastructure and all singletons that never, ever, change. Then for each task, create a new Module that binds singletons for that task only. Use that module to create a child injector off of your global injector. Then, when the task is over simply throw away the child injector to clean up the garbage (assuming you clear up any additional references for things you pull out of the injector). Don't be afraid of duplicating some bindings if the objects depend on an interface being bound that might change per task. If you have a common set of duplications you can put them into a common module and either install that module in the task's module or create the child injector directly from the two modules. Nate On Sun, Oct 19, 2014 at 10:46 AM, Kevin Burton <[email protected]> wrote: > This is my understanding as well... > > However, my problem is that if I update the bindings , say by replacing > one with a new binding, then when I create the child injector it fails > because that binding was "already configured" > > I replace bindings because during init various systems changes. For > example, I have a bunch of threads for one task then a bunch of threads for > another. I have a 'Caller' that I use and change so that HTTP requests can > be logged based on which task performed the request. > > I guess one strategy would be to call getAllBindings on the injector and > then find all singletons, then merge the singletons into the new binding by > calling bind( Foo.class ).toInstance( ).. > > ... I think that would work but there are edge cases I am probably > missings. > > On Sunday, October 19, 2014 5:49:58 AM UTC-7, Nate Bauernfeind wrote: >> >> It sounds like you might want to use a childInjector pattern here. >> Structure it something like this: >> >> Global Injector binds everything that is truly a singleton in your >> project. Then in the service(s) where you want to be able to set some state >> and create a new object that references the global state create a >> childInjector. >> >> It's possible I don't completely understand your use case. Though, I >> think this should help you do what you want. >> >> Nate >> >> On Sun, Oct 19, 2014 at 12:47 AM, Kevin Burton <[email protected]> >> wrote: >> >>> Long story short, I've painted myself into a corner. >>> >>> I was creating new modules and a new injector in some code each time a >>> service started. >>> >>> The problem is I need to keep state by moving over singletons to the new >>> injector. >>> >>> The problem is, some of these bindings are now changes and possibly >>> replaced. >>> >>> Is it possible to migrate all existing singletons to a new injector with >>> new bindings? >>> >>> -- >>> 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. >>> To view this discussion on the web visit https://groups.google.com/d/ >>> msgid/google-guice/bcb4d057-1685-409e-ae6b-b66913d6464e% >>> 40googlegroups.com >>> <https://groups.google.com/d/msgid/google-guice/bcb4d057-1685-409e-ae6b-b66913d6464e%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/google-guice/3bfbaa8e-dfe5-42e0-9b96-fca6c4ae6033%40googlegroups.com > <https://groups.google.com/d/msgid/google-guice/3bfbaa8e-dfe5-42e0-9b96-fca6c4ae6033%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > 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. To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/CAHNex9-0eTJ%2B-%3Dom0HsAF_72ng5Jhij9D-2o5fXPZbbW9R3Ckg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
