On Sun, Sep 14, 2008 at 4:22 PM, Esko Luontola <[EMAIL PROTECTED]>wrote:
> > The above bindings appear to be functionally equivalent with the > following bindings (when the @TaskScoped annotation is removed from > the EntityManagerImpl class): > > bind(EntityManagerImpl.class).in(TaskScoped.class); > bind(EntityLoader.class).to(EntityManagerImpl.class); > bind(ReferenceFactory.class).to(EntityManagerImpl.class); > The best way to explain that is that to(...) always refers to another binding, implicit or explicit (I think you can also specify a Key there). So in this case, the second and third binding refer to the first binding, which is TaskScoped. This implicitly scopes these to be TaskScoped as well. > But my initial intuition was that it would be equivalent with the > following, which creates two instances of EntityManagerImpl per task: > > bind(EntityLoader.class).to(EntityManagerImpl.class).in(TaskScoped.class); > > > bind(ReferenceFactory.class).to(EntityManagerImpl.class).in(TaskScoped.class); In this case there is no binding for EntityManagerImpl, so Guice uses the implicit, no-scope binding to the type itself. Both bindings thus receive a different instance that they will @TaskScope. Is there some documentation which would help me to reach a correct > mental model on how the scopes and bindings are resolved? See Jesse's initial work at http://code.google.com/p/google-guice/issues/detail?id=213 Also note that my book has excellent coverage on what I explained above and more: http://www.apress.com/book/view/1590599977 Cheers Robbie --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
