On Feb 11, 2013, at 2:34 PM, Jan Algermissen <jan.algermissen_at_nordsc.com> wrote:
>
> On 11.02.2013, at 14:28, Bill Burke <bburke_at_redhat.com> wrote:
>
>> Injection of WebTargets require the configuration of an underlying Client. Client configuration will often require SSL configuration (truststore). Even without SSL, there's connection TTL, connection pooling configuration, and other things.
>>
>> I'm not a big fan of having functionality that requires vendor-specific configuration in order to work. This is why I think we should remove support for @Uri. I'm pretty sure it would be possible to write a CDI extension if users wanted to do this, but I think this is beyond the scope of the JAX-RS spec.
>
> I think so, too.
>
> Even more so, from my 'pure REST' POV: Clients should discover URIs at run time. The only known-up-front URIs should be those few entry URIs into a system....and those I'd really want in the configuration, not in the code :-)
>
> @Uri is nice for quick tryouts, though.
>
> Having said that: What was the original idea to have it?
Users request. They wanted to be able to inject client components.
FWIW, I do not buy Bills arguments. We do not expose TTL, pooling etc in the client API either. Does it mean we should remove it? Also, there's IMO nothing wrong to have a proprietary configuration for a managed JAX-RS client at this stage. We need to start somehow and see what pieces of the proprietary configuration should be standardised later.
Btw. @Uri is there since early June 2011!!! If we are now, few days before the PFD, discussing it's removal something is wrong.
Marek
>
> Jan
>
>
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>