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 Wed, 24 Dec 2014 10:18:36 GMT
On Wed, 2014-12-24 at 10:08 +0100, Stéphane Nicoll wrote:
> 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.
> 

Implemented in SVN trunk

http://svn.apache.org/r1647755

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

What is wrong with copying existing config and selectively changing some
parameters?

---
RequestConfig config1 = RequestConfig.custom()
        .setAuthenticationEnabled(false)
        .build();

RequestConfig config2 = RequestConfig.copy(config1)
        .setAuthenticationEnabled(true)
        .setSocketTimeout(1000)
        .build();
---

Cheers

Oleg

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



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