On Aug 30, 2010, at 11:16 AM, Alexandru Popescu ☀ wrote:
>>> 4. A new question that arose while looking at the jersey-guice in
>>> 1.3
>>> and the sample code is: who is actually injecting the values.
>>>
>>> The PerRequestResource is defined as:
>>>
>>> [code]
>>> @Path("bound/perrequest")
>>> @RequestScoped
>>> public class PerRequestResource {
>>>
>>> @Context UriInfo ui;
>>>
>>> @QueryParam("x") String x;
>>>
>>> private final SingletonComponent sc;
>>>
>>> @Inject
>>> public PerRequestResource(SingletonComponent sc) {
>>> this.sc = sc;
>>> }
>>>
>>> }
>>> [/code]
>>>
>>> While it is clear that Guice will manage the lifecycle of this
>>> resource (per request) and will inject the SingletonComponent
>>> through
>>> the constructor, it is not clear who will provide @Context UriInfo
>>> and
>>> @QueryParam("x") String
>>>
>>
>> Guice will inject everything related to @Inject. Jersey will inject
>> everything related to the JAX-RS annotations. Basically after Guice
>> instantiates and injects Jersey will have a go injecting.
>>
>>
>>> I know this mail got really long, so I apologize in advance for the
>>> effort to go through it while still hoping to get some help from the
>>> more experienced people on the list.
>>>
>>
>> Np, hth,
>> Paul.
>
>
> To see if I got this right: the only limitation of the current
> integration is that you cannot use both @Inject and @*Param on
> constructors, methods or fields. Is this correct?
Yes, in the sense that Jersey cannot tell Guice how to provide
bindings for such @*Param annotated types.
Ideally i would like Jersey to provide all bindings to Guice. Then it
would not be necessary for Jersey to inject after Guice has
instantiated and injected.
> If so, I'll give it
> a try to see if it really is a limitation or you can easily work
> around it.
>
The main limitation i have found is one cannot use constructor
injection with @*Param annotated types. Which is a shame since it is
recommended to utilize constructor injection whenever possible.
> I'll make sure I'll study all the links you've provided.
>
> thanks so much,
>
Np,
Paul.