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> 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 do not like the idea of the user writing the cryptic code nothing to
do with the application flow.
Finally, the fact that this feature is used in Jersey does not justify
on its own pushing it into JAX-RS
Cheers, Sergey
>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com