On Jan 7, 2009, at 3:55 PM, Gerard M. Davison wrote:
> 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.
>
Ah! i did realize, thanks for pointing that out.
>>
>>
>>> 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!
>
WebBeans is scheduled for Java EE 6:
http://jcp.org/en/jsr/detail?id=299
More progress than closures (which now seems to have an almost zero
chance of getting into the Java language) :-)
Paul.