On 15/02/13 02:56, Bill Burke wrote:
>
>
> 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;
>>
>> ...
>> }
The above example looks useful, definitely can imagine how {name} can be
'transferred' to a different URI, but I wonder, if we do
@Uri("
https://mail.acme.com/accounts/{name}")
which is more realistic, how to get the container HTTPS configuration
applied, when absolute URI is used, I think this may be tricky, as it
may bypass the relevant configuration, I'll need to confirm it is
possible at all in CXF
Cheers, Sergey
>>
>>> 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.
>