jsr339-experts@jax-rs-spec.java.net

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

From: Bill Burke <bburke_at_redhat.com>
Date: Wed, 13 Feb 2013 16:29:07 -0500

On 2/13/2013 3:22 PM, Marek Potociar wrote:
>
> 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?

I'm saying you're better off just injecting your configured Client via
CDI, Spring, or plain-java-DI. Its not like this @Uri annotation is
some big convenience anyways:

@Uri("uri") WebTarget target;

vs.

@Inject Client client;
WebTarget target = client.target("uri");

In previous iterations of @Uri didn't you have an optional additional
CDI annotation to reference the configured Client instance to use?

@MyClient @Uri("uri") WebTarget target;

Users would then implement a Client injector for @MyClient annotation.
I'm not sure if that would work, but...




>>
>>> 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?
>

Well, for one, the server only has a truststore if it is requiring
two-way SSL: CLIENT CERT AUTH. The server has a keystore (its private
key and signed cert and CA). I think that could be shared. Not sure.
If it can, it will only be shareable if each remote server the the
client is talking to is using the same CA's to sign each of the remote
server's certs. If you follow me....

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com