On Mar 9, 2009, at 7:29 PM, Erdinc Yilmazel wrote:
> Hi Paul,
>
> I made tiny modifications in GuiceComponentProviderFactory. I did not
> need my resource instances to be managed by guice, I think jersey
> handles them perfectly.
I see in the source code you are always returning an instance of
IoCManagedComponentProvider, if the injector contains the class. This
signals to Jersey that the life-cycle of the components is managed by
the IoC container, Guice, but Jersey can inject it's own stuff onto
the component (hence the getScope method, so that Jersey knows what it
can inject).
> What I needed was being able to inject other
> service instances into my Root resources using guice. So unless I
> explicitly bind a resource interface to a resource class using a Guice
> module, it is managed by jersey, otherwise it is managed by guice.
OK.
>
> The getComponentProvider method in my implementation returns null
> unless there is a binding in the injector for the Class that was sent
> as an argument to the method.
>
> In the original implementation there is a try catch block in the
> getComponentProvider method. In this block it returns a
> GuiceInstantiatedComponentProvider for every class that does not have
> a binding in guice. I did not want this behavior so I replaced the
> try-catch block with the following:
>
>
> if (!injector.getBindings().containsKey(Key.get(c))) {
> return null;
> }
>
OK.
> I also did not need iterating all bound classes of the injector to
> check if they are Resources or Providers. (In the register method).
> This is because all my resource and provider instances are already
> registered in the resource config.
>
What we were trying to do with such functionality was so that
developers did not have to do any Jersey-specific registration, since
they would be registered by Guice already, which is what we can do
with Spring integration, but maybe Guice should be different in this
respect.
> I am sending my version of GuiceComponentProviderFactory in the
> attached file.
>
Thanks. I am glad that the integration is flexible and does not
require much code such that developers can support what they require
without too much trouble (although i realize this area could do with
more documentation).
Perhaps we need to be a bit more flexible with the Guice configuration
set up?
Paul.