On Feb 11, 2013, at 8:34 AM, 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?
Developers asking for it, several times as I recall. Especially those that have used @WebServiceRef in the past. I'm not convinced that we should drop it because SSL or any other configuration that cannot be accessed on the injected WebTarget. Perhaps we should consider additional annotations for that in the future (just like you can configure WS-Addressing, etc. on a @WebServiceRef).
-- Santiago