users@jax-rs-spec.java.net

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

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Wed, 13 Feb 2013 21:22:42 +0100

On Feb 13, 2013, at 7:50 PM, Bill Burke <bburke_at_redhat.com> wrote:

>
>
> On 2/13/2013 12:39 PM, Marek Potociar wrote:
>> 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.
>>
>
> I disagree it should be managed by the container...A CDI injector should be written by the user rather than it being managed by the container.

When did the CDI sneaked into the discussion?
>
>> Now for the potential improvements:
>>
>> As for the SSL setup, why can't we use the container's key/trust store
>> configuration by default?
>>
>
> Container's truststore is a totally different animal than the client's. The client's is for verify hosts, container's is for verifying clients.

Are you saying the two use cases cannot be served by the same store? Or are you saying they should not?

Marek

>
>> 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
>>
>
> -1.
>
> Bill
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com