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? 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. 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. This can't be right, what am I missing? 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] > >
