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

[jsr339-experts] Re: Apache HTTP Client + JAX-RS

From: Jan Algermissen <jan.algermissen_at_nordsc.com>
Date: Tue, 20 Nov 2012 20:51:08 +0100

On Nov 13, 2012, at 5:34 PM, Bill Burke <bburke_at_redhat.com> wrote:

> I actually think this is quite important to think about how Apache HTTP client effects JAX-RS. Specifically on the security stuff we're thinking about adding to the spec.
>
> For example, if you look at how you configure HTTPS and client-cert auth for Apache HC, you notice that you cannot really set things up on the fly, you can't really modify them on the fly either. These things need to be available before you make one connection with Apache HC client:
>
> * server truststore (for HTTPS)
> * client keystore (for client-cert auth)
> * In some situations a hostname verifier is needed.
>
> This is leading me to believe that simple security properties aren't gonna cut it and we're gonna need some builder API to bind security config to a Client or WebTarget. Basically a builder API says "I'm done configuring connection properties, you can build the DefaultHttpClient now!" I'm prototyping one at the moment and will be ready to propose something soon, but it would be cool to get your thoughts on this.

That's an interesting aspect, too.

My issues are with connection handling. Right now, ClientFactory.newClient() is IMHO just completely useless when you leave the playground and create production systems.

Yes, one can configure the client after getting it, but that is probably too late.

What is our story on this? Is it that JAX-RS 2.0 simply provides ClientFactory as a base interface and that our expectation is that implementations will extend ClientFactory with a more configurable subclass?

E.g.

PerThreadConnectionPoolAwareFactory factory = PerThreadConnectionPoolAwareFactory.getInstance()

Client client = factory.getClient(); // to get a client using a certain upstream connection pool

...

The provided ClientFactory interface in 2.0 would then really only be 'informative', not to be used in practice really.

Would be fine with that, but I am interested in your opinion.

Jan




>
> On 11/12/2012 9:33 AM, Jan Algermissen wrote:
>>
>> On Nov 12, 2012, at 3:30 PM, Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com> wrote:
>>
>>>
>>> On Nov 12, 2012, at 6:52 AM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
>>>
>>>> On 11/11/12 19:21, Jan Algermissen wrote:
>>>>> Marek, Santiago,
>>>>>
>>>>> can you provide any preview of how Apache-Client support will look in Jersey's Apache package?
>>>>>
>>>>> I would like to explore the implications of the new configuration and async aspects in combination with Apache's client 'specialties'.
>>>>
>>>> Is is a spec related issue ? I'd assume this should be discussed on the Jersey list
>>>
>>> Yes. Jan, please forward your question to the Jersey alias.
>>
>> Sorry - I was thinking this over and since I am primarily interested in the implications the new API has when using a client such as Apache I felt the EG was the better list. If you object, never mind. I'll take it elsewhere.
>>
>> (just so you know I did not carelessly put it here)
>>
>> Jan
>>
>>>
>>> -- Santiago
>>>
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com