dev@jersey.java.net

Re: [Jersey] GuiceComponentProviderFactory seems to eagerly support resources that are not explicitly bound in the given Injector.

From: Charlie Knudsen <charlie.knudsen_at_gmail.com>
Date: Thu, 24 Sep 2009 01:14:07 -0500

On Wed, Sep 23, 2009 at 7:58 AM, Jae Lee <jlee119_at_gmail.com> wrote:
> Hi Paul,
> Yes, one specific use case of using multiple independent injectors are when
> you've got two independent resources with dependency to the common interface
> (in my example that will be Message), which then you might want each
> resource to depend on different implementation of the common interface (in
> my example that will be HelloWorld and HelloMe)
> I have to say the use case mentioned above is hypothetical, and I made it up
> to demonstrate the current behaviour.
> A more general use case of using multiple injectors that I'm really coming
> from would be when you want clear separation between group of resources
> (vertical slice of application) and thus you want to manage dependencies for
> those resources independently.
> With my understanding, it's OK to turn off the implicit instantiation,
> because those root level classes that Jersey recognises are all explicitly
> bound in the given Injector anyway... then actual instantiation will be done
> by Guice which then might instantiate some implicitly bound dependencies.
> It's just somewhat weird to see all Injectors other than the first one are
> ignored by ResourceComponentProvider, and totally different Injector is used
> to construct Resource that wasn't bound within.
> J

My understanding of Guice was that you should never have more than one
injector involved in an application. My understanding is that any
@Singleton class created by an injector is only a singleton for that
one injector and that if you have 2 injectors in one application you
would have one instance per injector, and therefore have 2 instances
of the singleton. When I need 2 different implementations of a single
interface, as you mention above, generally I annotate each differently
and then bind the implementation to both the interface and the
implementation.

Charlie