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:
>
>> On 30/08/12 17:01, Bill Burke wrote:
>>>
>>>
>>> On 8/30/2012 9:28 AM, Marek Potociar wrote:
>>>>
>>>> On Aug 29, 2012, at 11:56 PM, Bill Burke <bburke_at_redhat.com
>>>> <mailto:bburke_at_redhat.com>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 8/29/2012 10:09 AM, Bill Burke wrote:
>>>>>>
>>>>>> This may be supported already in CDI Beanmanager. I'll ask my CDI
>>>>>> guys.
>>>>>>
>>>>>
>>>>> CDI supports EJB reference lookup too. CDI 1.1 is simplifying
>>>>> BeanManager interface too. So, I'm not 100% against this feature like
>>>>> I was @ManagedAsync, but I'm not in favor of it at this moment.
>>>>
>>>> That's great news! Can you share the relevant docs pointers?
>>>>
>>>
>>> Errr...no, not without reading the spec, but I asked the CDI 1.1 spec
>>> lead.
>>>
>>>>> As I said before, I would be interested in a Servlet.forward()
>>>>> feature. Something like:
>>>>>
>>>>> interface ResourceContext {
>>>>>
>>>>> void forwardFromBase(String relativePath);
>>>>> void forwardAbsolute(String path);
>>>>> }
>>>>>
>>>>>
>>>>> IMO, CDI integration with JAX-RS combined with a forwarding interface
>>>>> pretty much covers the use cases you're interested in.
>>>>
>>>> While I'm not against the methods above, I quite strongly feel about
>>>> keeping the getResource() method in. There's still world beyond CDI
>>>> that I want to support. If users want to use CDI, very well. But there
>>>> are users who don't.
>>>>
>>>
>>> 1st. I just really can't support getResource(). If users don't want to
>>> use the full capabilities of Java EE, IMO, they are on their own. JAX-RS
>>> should not be in the dependency injection abstraction business. For most
>>> uses of resource locators, EJB, CDI, Spring, or Guice injection works
>>> fine. For more complex cases CDI Bean Manager or a Spring bean factory
>>> will work. Also, regular java *constructors* work pretty well too! And
>>> there is always parameter injection of jAX-RS data instead of field
>>> injection.
>>>
>>> 2nd. I just don't think match() is appropriate and you haven't shown me
>>> a usecase where it is. This is because I think users are more interested
>>> in *routing* requests, not the actual match itself.
>>>
>>> 3rd. You haven't shown me a use case that couldn't be supported with
>>> existing JAX-RS 1.1 and its integration with Java EE, EJB, and CDI.
>>>
>>> 4th JAX-RS should not be involved in the IoC/DI business.
>>>
>>> 5th Sergey and others PLEASE COMMENT ON THIS!
>>>
>>
>> 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
>
>>
>> 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
Cheers, Sergey
> Marek
>