Well, in the most basic case, this is as designed
bind( Runnable.class ).to( MyThing.class );
bind( Callable.class ).to( MyThing.class ).in(Scope.REQUEST);
If you @Inject a Runnable or a Callable, you get a MyThing like you'd
expect. So far, so good.
But if you want MyThing scoped (for example, as is a singleton), then
you have to sope the "MyThing" binding. using something like bind
(MyThing.class).in( Scopes.SINGLETON ).
If you prefer @Singleton, then to work around that, what I've done is
just introduce some level of indirection in your module
@Provides Runnable provideMyThingRunnable( MyThing thing ) {
return thing;
}
@Provides Runnable provideMyThingCallable( MyThing thing ) {
return thing;
}
You can of course use "toProvider" and a manual provider if you don't
care for @Provides methods.
The underlying concept is that before we have two bindings
1. Runnable->MyThing
2. Callable->MyThing
after, we have three
1. Runnable->@Provides method
2. Callable->@Provides method
3. MyThing->MyThing (Or CashMachine -> CacheMachineImpl)
The third binding is the one that caries the custom scope (singleton,
in this case), if that makes any sense.
Hope this helps.
-d
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"google-guice" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/google-guice?hl=en
-~----------~----~----~----~------~----~------~--~---
