> Good catch. It technically isn't needed in my example. But, consider the
> case where it's not split between Foo -> FooImpl, or if FooImpl was scoped
> (as, say, a @Singleton annotation on FooImpl). If it had a scoping
> annotation, toConstructor basically ignores that scope. For concrete
> classes, you need toConstructor because otherwise you'll get recursion.
> Consider:
> bind(ConcreteFoo.class).annotatedWith(Internal.class).to(ConcreteFoo.class);
> bind(ConcreteFoo.class).toProvider(new
> SpyProvider(getProvider(Key.get(ConcreteFoo.class, Internal.class)));
> ConcreteFoo is bound to SpyProvider, which will be using a Provider of
> "@Internal ConcreteFoo", which is bound to ConcreteFoo... and then repeat.
> Using toConstructor(...) in the first binding gets rid of the recursion,
> because "@Internal ConcreteFoo" is bound to a "constructor of ConcreteFoo".
Bingo! That's exactly the problem I was running into. (I remember
trying almost exactly what you proposed.) I'll move Jukito's
SpyProvider to a toConstructor binding as soon as Guice 3 is
realeased.
Thanks again, and major kudos for a beautiful tool,
Philippe
--
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.
