On 2/12/2013 11:28 AM, Marek Potociar wrote:
>
> 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.
>
Users are often misguided or do not know the larger picture.
> 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?
You're picking out one thing (TTL/pooling) to disregard my whole
argument. SSL is a huge chunk of traffic. Whether it will be a
majority or not is application specific. And SSL usually requires
specific configuration. Even more so within a testing environment.
And, when you think about it, it's not just SSL. What about registering
MBW/MBRs? Filters for authentication (i.e. Basic Auth)? Both of which
will be really really common!
> 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.
>
I really can't think of any other JAX-RS feature that requires external,
proprietary, configuration in order to work. Anybody using @Uri +
HTTPS, Basic Auth, or have the need for a specific
MBW/MBR/Filter/Interceptor will now be *unportable*.
> Btw. @Uri is there since early June 2011!!! If we are now, few days before the PFD, discussing it's removal something is wrong.
>
I fail to see your point. Our SSL discussions are very recent and
relevant to this discussion. So much so, it caused me to rethink my
position on this feature.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com