On Aug 30, 2012, at 5:01 PM, Bill Burke <bburke_at_redhat.com> 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.
JAX-RS from the very beginning is trying to keep the amount of hard dependencies on a JavaEE container at the absolute minimum. That light-weight nature is one of the aspects that made JAX-RS so successful IMO. I think it should be obvious now that I'm open to consensus and changes if it's for the benefit of JAX-RS users. But frankly, this time the discussion smells more like politics to me, because while the end-user convenience arguments don't seem to apply in this conversation.
I am not arguing that injection provided by other DI containers does not work. I'm arguing that the users should be able to inject JAX-RS resources using a single API bridging all specific DI container APIs. As for regular constructors, if you remember our earlier discussion on the subject, we were also proposing to add injection methods that would inject JAX-RS artifacts into a constructed sub-resource instance. I can add that to the API. It would be a nice convenience method too.
> 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.
As I said, I'm fine with replacing those with the forward methods you've suggested.
> 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.
JAX-RS is not bound to run just in the context of Java EE and CDI is not the only injection technology out there.
> 4th JAX-RS should not be involved in the IoC/DI business.
This is ridiculous. JAX-RS has been in the IoC and DI business since it's inception, long before CDI was proposed. How can you ignore that...
> 5th Sergey and others PLEASE COMMENT ON THIS!
Seems like the only point I can 100% agree with. And I'd like to hear more from the JAX-RS users side in the EG.
Marek