users@jersey.java.net

Re: [Jersey] Injection only at the top level resource?

From: Gerard M. Davison <Gerard.Davison_at_oracle.com>
Date: Wed, 07 Jan 2009 14:55:49 +0000

Paul Sandoz wrote:
> On Jan 7, 2009, at 3:22 PM, Gerard M. Davison wrote:
>
>>
>> Paul,
>>
>> Thanks, that seem reasonable. At least in the case I am looking at I
>> need to pass some parameters to the created resource object. I guess
>> that the middle two are the most useful in my case. (@Resource
>> doesn't appear to be attachable to a method parameter otherwise I
>> would quite happily be using that)
>>
>
> Hmm... it should work in conjunction the InjectableProvider you
> created and registered. The reason is that all the other injection
> support is implemented the same way (e.g. @Context for injection of
> ResourceContext in the example in my previous email). If not then it
> is a bug i need to fix.

Ah this is because of the definition of @Resource and not because of a
bug in Jersey. It cannot be attached to method parameters:

http://java.sun.com/javase/6/docs/api/javax/annotation/Resource.html

So more a bug in JSR 250 than anything else.

>
>
>> Perhaps a suggested enhancement would be to extend ResourceContext
>> with either:
>>
>> 1. Allow args constructors
>>
>> <T> T getResource(Class<T> c, Object... args)
>>
>
> Yes, i was pondering about that as well. Note that it is also possible
> to have annotated parameters on constructors. See the section "Rules
> of Injection" in the following document:
>
> http://wikis.sun.com/display/Jersey/Overview+of+JAX-RS+1.0+Features
>
>
>> 2. Allow post creation injection
>>
>> <T> T inject(T input)
>>
>
> To correctly inject Jersey needs to know the life-cycle (e.g. per
> request or singleton) of what it is injecting stuff on to.
>
> Of course things would be a little different if there was an IoC
> framework standardized when we specified JAX-RS :-) which is what we
> really need.

Ah yes, sorry that make sense and along with the context in your later
EE comment. I guess I was trying to be a little bit too cheap. And yes a
standard for IoC would be nice but I could see that being even harder to
JSR than the closures!

Thanks,

Gerard

>
>
>> But I could understand you not wanting to go down this route and wait
>> until the JEE integration is finished.
>>
>
> I think what you suggest above is independent of the EE integration,
> since management and injection will never be performed on instances
> returned from sub-locator resources.
>
> Paul.
>
>> Again thanks for your answer,
>>
>> Gerard
>>
>>
>>