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

[jsr339-experts] Re: [jax-rs-spec users] Re: Re: Re: Re: I'd like to remove @Uri

From: Bill Burke <bburke_at_redhat.com>
Date: Thu, 14 Feb 2013 21:56:05 -0500

On 2/14/2013 4:52 PM, Marek Potociar wrote:
>
> On Feb 13, 2013, at 10:29 PM, Bill Burke <bburke_at_redhat.com
> <mailto:bburke_at_redhat.com>> wrote:
>
>>
>>
>> On 2/13/2013 3:22 PM, Marek Potociar wrote:
>>>
>>> On Feb 13, 2013, at 7:50 PM, Bill Burke <bburke_at_redhat.com
>>> <mailto:bburke_at_redhat.com>> wrote:
>>>
>>>>
>>>>
>>>> On 2/13/2013 12:39 PM, Marek Potociar wrote:
>>>>> Bill, Jan, Sergey et al.,
>>>>>
>>>>> Even without any improvements, one of the benefits of using WebTarget
>>>>> injection is that since resources are primarily request-scoped, users
>>>>> would need to somhow manage client and target instances to avoid
>>>>> repeated initialization of client-side artifacts. With @Uri, the
>>>>> initialization can be managed by the JAX-RS container relieving the
>>>>> user
>>>>> and improving performance. That should work at least for basic cases. I
>>>>> think that this use case alone is enough to keep the @Uri in the API.
>>>>>
>>>>
>>>> I disagree it should be managed by the container...A CDI injector
>>>> should be written by the user rather than it being managed by the
>>>> container.
>>>
>>> When did the CDI sneaked into the discussion?
>>
>> I'm saying you're better off just injecting your configured Client via
>> CDI, Spring, or plain-java-DI. Its not like this @Uri annotation is
>> some big convenience anyways:
>>
>> @Uri("uri") WebTarget target;
>>
>> vs.
>>
>> @Inject Client client;
>> WebTarget target = client.target("uri");
>>
>
> Well, putting aside a fact that your solution is not portable,

It certainly is very portable in an EE environment. But there's no
requirement to use CDI to inject a Client. You could certainly use
Spring or simple POJO DI.


> one thing
> that is helpful is automated template subtitution based on the matched
> request URI parameters. That's something you would not be able to easily
> do with CDI/Spring/DI. For example:
>

* How often is are fragments of one URI scheme transferable to a
different URI scheme? Rarely. URI Templates are far more useful than
this bizarre feature of transferring uri segments from one scheme to
another.

* Why would anybody ever want a WebTarget that pointed back to the same
server? That is just really bad practice. A much better practice is
encapsulating logic within EJBs, CDI, Spring beans, or POJOs and
delegating to those objects rather than doing a full HTTP loopback
request.

I've already submitted a separate JIRA for the above complaints.

> @Path("users/{name}")
> public class MyResource {
> @Uri("users/{name}/orders")
> WebTarget userOrders;
>
> @Uri("http://mail.acme.com/accounts/{name}")
> WebTarget userEmailAccount;
>
> ...
> }
>
>> In previous iterations of @Uri didn't you have an optional additional
>> CDI annotation to reference the configured Client instance to use?
>>
>> @MyClient @Uri("uri") WebTarget target;
>>
>> Users would then implement a Client injector for @MyClient annotation.
>> I'm not sure if that would work, but...
>
> No, I did not have any proposal that would rely directly on CDI.

And I'm completely against adding a JAX-Rs specific thing to configure
one, pretty much trivial feature. It would be very different if this
was some core feature, but @Uri certainly isn't.

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