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

From: Bill Burke <bburke_at_redhat.com>
Date: Tue, 12 Feb 2013 13:22:15 -0500

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