On Sep 3, 2012, at 1:53 PM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
> Hi Marek
> On 31/08/12 14:42, Marek Potociar wrote:
>>
>> On Aug 30, 2012, at 7:38 PM, Sergey Beryozkin <sberyozkin_at_talend.com
>> <mailto:sberyozkin_at_talend.com>> wrote:
>>
>>>
>>> I'm against this feature. It appears, from the JIRA issue Marek linked
>>> to, it was mainly about supporting the injection into EJB
>>> subresources. It's not a JAX-RS concern - I agree with Bill.
>>
>> I finally found another MAJOR issue that has been closed as a duplicate
>> of JAX_RS_SPEC-72:
>> http://java.net/jira/browse/JAX_RS_SPEC-35
>>
>> Note the larger scope of the original issue. Also kindly check our older
>> discussions on this:
>> http://java.net/projects/jax-rs-spec/lists/jsr339-experts/archive/2012-04/message/17
>>
>>>
>>> I do not like the idea of the user writing the cryptic code nothing to
>>> do with the application flow.
>>
>> I'm not sure what you mean. Can you provide example of such cryptic code?
>
> resourceContext.matchResource()
>
> I'm sorry, 'cryptic' is the wrong word, it is the idea of the user having to do something 'opaque' to get one of the application classes chosen (as opposed to the runtime doing it or opposed to the user writing a code which one can read and get what is going on) that makes me uncomfortable
I think I'm fine with removing match methods from the ResourceContext API. We may instead consider introducing the "forward" methods Bill (and you?) were proposing (but even that it's not a must).
In case of resource injection methods, we see that there's a real need for it. And unless we do want to make JAX-RS strongly dependent on CDI it is better to introduce a bridging API directly in JAX-RS. Now, as for hard CDI dependency in JAX-RS, I personally prefer we do not introduce it.
A personal note: I believe it makes a lot of sense to continue working on supporting a tighter integration between JAX-RS and CDI in Java EE environment, e.g. such that in a JavaEE container, the resource management is delegated to CDI (at least whenever possible - note that CDI still does not support non-proxiable beans, e.g. final classes, while JAX-RS does). However, for the sake of retaining the current independence of JAX-RS on other Java EE specs and implementations when running in JavaSE environment, I'd like to avoid hard CDI dependency. Many of our users are happy using DI frameworks of their choice when running in plain Java SE. I don't see why we should force a somewhat heavy-weight technology with a single implementation (AFAIK) upon those users.
>>
>>>
>>> Finally, the fact that this feature is used in Jersey does not justify
>>> on its own pushing it into JAX-RS
>>
>> You are right. However, the fact that users want it, including some of
>> the JAX-RS users in this EG, does provide quite strong justification.
>>
> Agreed.
>
> Let me ask a question: this ResourceContext API, do you see it as a light weight alternative to CDI, Spring, etc ? Or do you see it bringing something on its own that can not be managed easily enough with those technologies ?
>
> Example, if I really, really wanted to get a subresource injection working without wishing to spend the time on explicitly calling setters on subresource instances, then I'd probably consider using say Spring lookup methods, in cases when say no EE container is used, or I guess CDI.
>
> I've said I'm against the feature but I guess I haven't given it a proper consideration, so hope I can do it better this time
I think that resource context is something that could potentially provide or expose JAX-RS resource related/specific features such as:
- a bridging injection API for any supported underlying injection manager (whether the JAX-RS internal one or a one externally provided by Spring, Guice, CDI ...) that let's you conveniently inject sub-resources in a way independent of the underlying injection manager to be used. IOW, it would work outside EE as well as inside EE without any need for explicit CDI/Spring/Guice/... dependency in the application code. This one is the most important feature and the minimum that we should support IMO. Our users use it a lot.
- forwarding/matching requests based on custom URIs - basically a way to expose matching engine to the application user. I don't feel strongly about this one.
- other useful resource-specific information, essentially anything that users find as missing and relates to resources, their instantiation and matching. E.g. providing a list of all resource classes matching the request URI (with new support for multiple resource classes on a same path might help to improve e.g. manual generation of OPTIONS response), etc. I don't feel strongly about these either, it's something that could be added into the API over time based on the user requests.
HTH,
Marek