Re: Creating a new injector, with new bindings, but keep all singletons?
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 burtona...@gmail.com 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 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. 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=emailutm_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 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. To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/CAHNex99n0RxfgUMJUsF23GWMNbSxsRqSxQW%3DJ6iX8YUG2OeTDg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Creating a new injector, with new bindings, but keep all singletons?
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 burtona...@gmail.com 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 burto...@gmail.com 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 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. 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=emailutm_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 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. 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=emailutm_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 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. To view this
Re: Creating a new injector, with new bindings, but keep all singletons?
I'm aware that it's probably that I might need to refactor some things ... However, I'm not sure the ideal way to have certain bindings, without replacing them. I have one binding, Caller, which is literally just a string explaining what root service called an object. This way I can trace things like how an HTTP request originated. By default, it's unknown... because any library should be able to perform an HTTP request if necessary. However, I need to swap in a new one as I'm starting up certain tasks. So if I have a Foo and a Bar task each should have its own Caller. And yes, you might be right... I may need to rethink some of my bindings... some of these aren't completely obvious though. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/41e3b741-ec9b-49a2-bebe-b8881bd48aa7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Creating a new injector, with new bindings, but keep all singletons?
Do you ever run two tasks simultaneously? If not, perhaps you can create a
special provider that you can swap out the Caller where you're currently
considering creating a new injector.
import com.google.inject.Provider;
import java.util.concurrent.atomic.AtomicReference;
public class CallerProvider implements ProviderCaller {
private AtomicReferenceCaller caller;
public void set(Caller currentCaller) {
caller.set(currentCaller);
}
@Override
public Caller get() {
return caller.get();
}
}
Inject ProviderCaller anywhere you need to know who the caller is (when
logging, etc) and call .get() to get the current caller. Consider using a
ProviderOptionalCaller or at least be careful of null pointer
exceptions when Caller is not set.
Does this help you get to a solution? Are there other things you were
hoping to replace by creating a new injector that doesn't fit into this
pattern?
On Sun, Oct 19, 2014 at 11:54 AM, Kevin Burton burtona...@gmail.com wrote:
I'm aware that it's probably that I might need to refactor some things ...
However, I'm not sure the ideal way to have certain bindings, without
replacing them.
I have one binding, Caller, which is literally just a string explaining
what root service called an object.
This way I can trace things like how an HTTP request originated.
By default, it's unknown... because any library should be able to perform
an HTTP request if necessary.
However, I need to swap in a new one as I'm starting up certain tasks.
So if I have a Foo and a Bar task each should have its own Caller.
And yes, you might be right... I may need to rethink some of my
bindings... some of these aren't completely obvious though.
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-guice/41e3b741-ec9b-49a2-bebe-b8881bd48aa7%40googlegroups.com
https://groups.google.com/d/msgid/google-guice/41e3b741-ec9b-49a2-bebe-b8881bd48aa7%40googlegroups.com?utm_medium=emailutm_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 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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-guice/CAHNex9-2Wn2_xdsgW%3D8wurkw16p2ZkU2cQdm770DLs3KA-cEgw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: Creating a new injector, with new bindings, but keep all singletons?
You can also use custom scopes to change the returned instance depending
on your logic.
This may be a little cleaner than having too much logic in the providers.
On 10/19/2014 06:55 PM, Nate Bauernfeind wrote:
Do you ever run two tasks simultaneously? If not, perhaps you can
create a special provider that you can swap out the Caller where
you're currently considering creating a new injector.
import com.google.inject.Provider;
import java.util.concurrent.atomic.AtomicReference;
public class CallerProvider implements ProviderCaller {
private AtomicReferenceCaller caller;
public void set(Caller currentCaller) {
caller.set(currentCaller);
}
@Override
public Caller get() {
return caller.get();
}
}
Inject ProviderCaller anywhere you need to know who the caller is
(when logging, etc) and call .get() to get the current caller.
Consider using a ProviderOptionalCaller or at least be careful of
null pointer exceptions when Caller is not set.
Does this help you get to a solution? Are there other things you were
hoping to replace by creating a new injector that doesn't fit into
this pattern?
On Sun, Oct 19, 2014 at 11:54 AM, Kevin Burton burtona...@gmail.com
mailto:burtona...@gmail.com wrote:
I'm aware that it's probably that I might need to refactor some
things ...
However, I'm not sure the ideal way to have certain bindings,
without replacing them.
I have one binding, Caller, which is literally just a string
explaining what root service called an object.
This way I can trace things like how an HTTP request originated.
By default, it's unknown... because any library should be able to
perform an HTTP request if necessary.
However, I need to swap in a new one as I'm starting up certain tasks.
So if I have a Foo and a Bar task each should have its own Caller.
And yes, you might be right... I may need to rethink some of my
bindings... some of these aren't completely obvious though.
--
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
mailto:google-guice+unsubscr...@googlegroups.com.
To post to this group, send email to google-guice@googlegroups.com
mailto:google-guice@googlegroups.com.
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/41e3b741-ec9b-49a2-bebe-b8881bd48aa7%40googlegroups.com
https://groups.google.com/d/msgid/google-guice/41e3b741-ec9b-49a2-bebe-b8881bd48aa7%40googlegroups.com?utm_medium=emailutm_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 google-guice+unsubscr...@googlegroups.com
mailto:google-guice+unsubscr...@googlegroups.com.
To post to this group, send email to google-guice@googlegroups.com
mailto:google-guice@googlegroups.com.
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-2Wn2_xdsgW%3D8wurkw16p2ZkU2cQdm770DLs3KA-cEgw%40mail.gmail.com
https://groups.google.com/d/msgid/google-guice/CAHNex9-2Wn2_xdsgW%3D8wurkw16p2ZkU2cQdm770DLs3KA-cEgw%40mail.gmail.com?utm_medium=emailutm_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 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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-guice/544407CA.2090906%40gmx.ch.
For more options, visit https://groups.google.com/d/optout.
