hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stéphane Nicoll <snic...@pivotal.io>
Subject Re: access to default RequestConfig
Date Wed, 24 Dec 2014 09:08:44 GMT
On Tue, Dec 23, 2014 at 8:20 PM, Oleg Kalnichevski <olegk@apache.org> wrote:

> On Tue, 2014-12-23 at 17:48 +0100, Stéphane Nicoll wrote:
> > On Mon, Dec 22, 2014 at 5:11 PM, Oleg Kalnichevski <olegk@apache.org>
> wrote:
> >
> > > On Mon, 2014-12-22 at 15:11 +0100, Stéphane Nicoll wrote:
> > > > Hi,
> > > >
> > > > I am working on the Spring framework and we are trying to properly
> update
> > > > some of our helper classes to HC 4.3[1]. 4.3 has moved some
> configuration
> > > > to a RequestConfig object and does not allow the HttpClient to be
> > > > customized once it has been built (as far as I can see!).
> > > >
> > > > Our factory has the ability to set the read or connection timeout in
> a
> > > > convenient way and we make sure to update the underlying
> infrastructure.
> > > > With 4.3 we have moved that code to the creation of a custom
> > > RequestConfig
> > > > instance per request based on the state of the factory.
> > > >
> > > > Instead of overriding everything as we do know, I'd like to be able
> to
> > > > *merge* our customizations with the default settings of the current
> http
> > > > client. But there is no accessor to the default RequestConfig
> object. Is
> > > > that intended?
> > > >
> > >
> > > Hi Stéphane
> > >
> > > Yes, it was intended. The process of request execution should be
> > > customized through HttpContext instance associated with individual HTTP
> > > exchanges. HttpClient instances can be configured to provide some
> global
> > > defaults in case HttpContext has not been explicitly specified.
> > >
> > > One could use a custom protocol interceptor to get hold of the default
> > > RequestConfig instance and replace it with a new one, but such
> > > interceptor would need to be added to the protocol execution chain at
> > > the client's construction time.
> > >
> >
> > Rossen and I had an extra look and we have a few more questions. Looking
> at
> > your PR[1], you are actually always returning a RequestConfig object no
> > matter what which actually prevents the client's default to apply. Did
> you
> > really intended to do that?
> >
>
> Probably not.
>
> > I have updated that code, see 9b399623e[2] to take the client's defaults
> if
> > no customization is applied on the factory. This seems to be working
> fine.
> > Yet, being able to access the client's defaults would be really nice for
> us
> > because it means that a customization of one parameter can be merged
> > (copied) from the client's default.
> >
>
> What I could do is to make internal HttpClient class also implement
> Configurable. It is not particularly nice but we already do that for
> HttpRequest instances anyways.
>
> Would that solve the problem for you?
>

That's exactly what we discussed so that would help us, yes. Thanks!


>
> > The test named
> "defaultSettingsOfHttpClientLostOnExecutorCustomization"[3]
> > illustrates what I mean concretely. Unless I am missing something, this
> > illustrates a limitation in the current API: if you have configured an
> > HttpClient with a bunch of settings and then you want to change *one*
> > parameter for a given request, you loose all those settings because you
> > have no way to merge them.
> >
>
> Prior to 4.3 we had a very flexible configuration APIs that allowed for
> parameter hierarchies, parameter overrides, runtime configuration
> mutability, time travel and what not. However, some people kept on
> bitching loudly about config API being too "un-Java" and too complex. As
> of 4.3 HttpClient has a much simpler and a more straight-forward config
> APIs. No more merges, no more magic, no more time travel.
>
> From where I sit this problem has more to do with Spring being a little
> too invasive rather than HttpClient APIs being too limiting.
>

Well, we have a contract that is rather simple and we just want to find a
way to make it backward compatible. Your suggestion will help so let us
know when you've done that please.

On a more personal note, I think there is a difference between what you're
describing and "simply" being able to merge the default of the client with
a particular customization. RequestConfig wraps a lot of things so if you
want to customize only a few properties, you have to keep a handle to both
the HttpClient and its RequestConfig to be able to tune something and keep
your other customizations. I am actually wondering how others are handling
that use case. Like I said, I may be missing something...

Cheers,
S.


>
> > This can't be right, what am I missing?
> >
>
> It really depends.
>
> Oleg
>
> > Thanks!
> > S.
> >
> >
> > [1]
> >
> https://github.com/spring-projects/spring-framework/commit/296e2189a2376745414a065e9239b066c31e2bed
> > [2]
> >
> https://github.com/snicoll/spring-framework/commit/9b399623ead96b0a4b386f248d320ccc0850aaa6
> > [3]
> >
> https://github.com/snicoll/spring-framework/commit/9b399623ead96b0a4b386f248d320ccc0850aaa6#diff-4d02946b2c9dc741cf90b2fa860b39e4R93
> >
> >
> > >
> > > > The only solution I could see would be to request the user to pass
> the
> > > > HttpClient to use *and/or* the default RequestConfig to use. That
> feels
> > > odd
> > > > since the latter can be set in the former (but I can't access it
> once the
> > > > client has been built).
> > > >
> > > > Thoughts?
> > > >
> > >
> > > I am afraid there is no elegant way out of this situation. One option
> > > might be to let the users provide an instance of HttpClientBuilder
> > > instead of HttpClient, which would enable Spring introduce additional
> > > interceptors to the protocol processing chain.
> > >
> > > Oleg
> > >
> > > > S.
> > > >
> > > > [1] https://jira.spring.io/browse/SPR-12166 -
> > > > https://jira.spring.io/browse/SPR-12540
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> > >
> > >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message