On Tue, Dec 23, 2014 at 8:20 PM, Oleg Kalnichevski <[email protected]> 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 <[email protected]> > 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: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
