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

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

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Thu, 14 Feb 2013 22:52:37 +0100

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

>
>
> 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");
>

Well, putting aside a fact that your solution is not portable, one thing that is helpful is automated template subtitution based on the matched request URI parameters. That's something you would not be able to easily do with CDI/Spring/DI. For example:

@Path("users/{name}")
public class MyResource {
    @Uri("users/{name}/orders")
    WebTarget userOrders;

    @Uri("http://mail.acme.com/accounts/{name}")
    WebTarget userEmailAccount;

    ...
}

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

No, I did not have any proposal that would rely directly on CDI. The above is something we are support in Jersey using our custom @ClientBinding annotation (which you -1-ed earlier). The reason for using the custom annotation rather than a DI @Qualifier is that we want to provide some additional data as part of the annotation, which is not possible with a qualifier.

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

It looks that you're indicating that there can be only a single key in a key store and only a single CA in the trust store. I'm not a big security expert, but I thought you can have more of each. Or maybe I do not follow...

Marek

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