hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: access to default RequestConfig
Date Tue, 23 Dec 2014 19:20:50 GMT
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?

> 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.      

> 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
View raw message