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.
Now for the potential improvements:
As for the SSL setup, why can't we use the container's key/trust store configuration by default?
As for TTL, pooling etc. I'm fine having this configured in a proprietary way for now.
As for a custom configuration setup, I think it's too late to propose anything, but we are already experimenting in Jersey with @ClientBinding annotation that can let users supply their own client configurations via Application.getClasses()/getSingletons():
http://jersey.java.net/nonav/apidocs/snapshot/jersey/org/glassfish/jersey/server/ClientBinding.html
I was hoping that we will have some more time to play with it, but if you want, we can still try to push this into the spec.
Marek
On Feb 12, 2013, at 7:22 PM, Bill Burke <bburke_at_redhat.com> wrote:
>
>
> 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