On Nov 27, 2008, at 8:21 AM, Jorge L. Williams wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>> I think it could be, the API is of course still young, but the design
>> was that WebResource encapsulates functionality of a resource, and
>> there may be different requirements for client communicating with the
>> resource. IIRC there were already some people setting the time out
>> options for different resources, another one could be redirection,
>> sometimes you need to, other times not. Same for credentials. Having
>> to have a new Client instance for each configuration is expensive.
>>
>
> I see.
>
Now i recall in more specific detail:
https://jersey.dev.java.net/issues/show_bug.cgi?id=132
>
>> Looking closer at the Apache HTTP client API it appears that:
>>
>> - HostConfiguration, HttpState can be passed to
>> HttpClient.executeMethod(...); and
>>
>> - It is possible to set parameters to the HttpMethod using
>> HttpMethodParams, which
>> is a super class of HttpClientParams. The only feature that
>> requires HttpClientParams
>> is HttpClientParams.setAuthenticationPreemptive.
>>
>> In this respect it seems possible to get most functionality working
>> in
>> a thread safe manner using the existing configuration approach. Is
>> that your understanding as well?
>>
>>
>
> Yes, I believe this is true.
OK, lets try and refractor along those lines.
>
>
>
>> I am open to suggestions on how we can change the API to support both
>> the HttpURLConnection and Apache HTTP configuration approach.
>>
>> There seem to be two sets of configuration options:
>>
>> 1) options that are configurable once per root client handler.
>>
>> 2) options that are configurable by the client, filter and
>> WebResource at runtime.
>>
>
>
> We could take the approach that HttpClient takes and actually have two
> different classes of configuration options. That makes the distinction
> that you're pointing out clear to the developer.
>
We can have this:
/**
* A root client handler at the end of the filter chain that is
responsible for processing
* a built client request returning the client response.
*/
public interface RootClientHandler extends ClientHandler {
/**
* Initiate the root client handler. Initialization properties
of the client configuration
* may be utilized.
*/
public init(ClientConfig cc);
}
and certain properties can be documented whether they apply on
initiation only.
> Another approach we could borrow from HttpClient is to pass
> configuration options directly to the Methods themselves. That makes
> the
> configuration ephemeral and we could say things like redirect in
> general
> but please don't redirect on this DELETE.
>
An interesting idea. Note that such an approach is possible by writing
a client filter and checking the HTTP method.
To be honest i am not a great fan of the Apache API, it seems overly
engineered.
>
>> Maybe the root client handler can also implement another interface
>> with an initialization method that takes the client config and looks
>> at certain properties that only apply to initialization e.g. the
>> preemptive auth.
>>
>
>
> I agree there needs to be a better connection between the root handler
> and the config.
>
>
>> In addition it might be possible to support an efficient Client.clone
>> method.
>>
>
>
> I'd much rather keep around multiple HttpStates, and Configurations
> and
> swap carefully between them than to have multiple HttpClients. As I
> understand, HttpClients are pretty resource heavy. Keep in mind that
> the connection manager associated with the client may actually open
> multiple connections to the server for example....
>
Agreed.
> On a side note, I keep debating whether to offer that as a
> configuration
> option -- the total number of maximum connections, and the maximum
> connections to a host --- see MultiThreadedHttpConnectionManager.
>
Yes.
We are going to release on Monday if all goes well with testing, but i
think the the Apache HTTP client integration is a little too immature
for the stable release, and i don't have the time between now and then
to make the changes, test and verify. Thus i am going to remove it
from the deploy to the maven repo, and we will schedule it to be in
the next stable release.
Paul.