On 09/01/13 21:05, Bill Burke wrote:
>
>
> On 1/9/2013 11:26 AM, Santiago Pericas-Geertsen wrote:
>>
>> On Jan 8, 2013, at 11:12 AM, Bill Burke <bburke_at_redhat.com> wrote:
>>
>>>
>>> https://github.com/resteasy/Resteasy/blob/master/jaxrs/resteasy-client/src/main/java/org/jboss/resteasy/client/jaxrs/AbstractClientBuilder.java
>>>
>>
>> I'm certainly not an SSL expert, but overall it looks good to me.
>> Seems to address keystores, SSL context, etc. Some questions:
>>
>> (1) Are there defaults for all these builder methods if not called? Or
>> will build() throw an exception if the building process is somehow
>> incomplete?
>>
>
> No failures if something not called.
>
> defaults are:
> * SSL connections will fail unless JDK's default truststore trusts the
> server you are connecting too. Disabling verification is a huge security
> hole.
> * Not defining a connection pool size, the pool size defaults to zero.
>
>> (2) What's the rationale/advantage of supporting per-hostname
>> connection pools here?
>>
>
> Just copying Apache Client. Could be total connections pooled, or whatever.
>
>> (3) Is there a relationship between this builder and Resteasy's
>> implementation of ClientFactory?
>>
>
> Its what we use at the moment. I'm already using it.
>
> I'm also thinking maybe we have a cookie flag that states whether
> cookies should be saved and transmitted or not.
>
>
> I think SSL, pooling, and cookies are all the major features of Apache
> Client that people use.
>
The API should not be centered around Apache Client, if this API can be
applied equally well to the default JDK URL connection/etc then it is
OK, otherwise not
Sergey