jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: [jax-rs-spec users] Re: Re: Re: FYI: ResourceContext API proposed

From: Bill Burke <bburke_at_redhat.com>
Date: Thu, 30 Aug 2012 11:01:01 -0400

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!



-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com