Paul.Sandoz_at_Sun.COM wrote on 11/27/2008 02:30:23 AM:
>
> >
> >> 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.
>
>
Sounds good.
> >
> >
> >
> >> 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.
>
>
Okay this will work.
>
> > 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.
>
>
I'm not sure I like the idea of having to require the use of a filter in
this case. Off hand, I think that may end up complicating the WADL2Java
code a bit --- we should at least provide some sort of a convenience
interface that allows this kind of customization.
> >
> >> 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.
>
>
Okay.
> > 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.
>
Yea, I should have added those options before I submitted.
> 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.
>
I understand. Any idea when you're planning for the next stable release?
I'm spread a little thin these days and won't have time to jump into this
until early next year. None the less, I'm really interested in helping
out as I have a customer that requires this functionality and I'd hate to
be redistributing non-stable branches of Jersy Client.
-jOrGe W.