Consider adding properties to toggle auto detecting ClientHttpRequestFactory for RestTemplate creation

[ttddyy]

When creating a RestTemplate from spring-boot auto-configured RestTemplateBuilder, by default, it auto detects ClientHttpRequestFactory from loaded libraries by ClientHttpRequestFactorySupplier.
This is based on RestTemplateBuilder.detectRequestFactory is true by default.

The back story is that this auto-detection bit us. When some of the apps changed the RestTemplate bean definition from directly instantiating RestTemplate to use spring-boot auto-configured RestTemplateBuilder, this auto-detection kicked in and found http-client in the path and enabled connection-pooling. For those apps, due to unfortunate infra issue, we cannot use connection pooling for now, but the connection-pool has sneaked in by this auto-detection.

To stop this auto-detection, currently application is required to define a custom RestTemplateBuilder or RestTemplateCustomizer.

I would like to suggest a property to toggle this behavior, so that no bean definition is required to disable the auto detection.

For implementing aspect, let's say have a property spring.rest-template.detect-request-factory.enabled, and based on the value, toggle RestTemplateBuilder.detectRequestFactory in RestTemplateAutoConfiguration.

If this sounds good, I'll create a PR.

Thanks,

[wilkinsona]

Sorry that you were bitten by the default behaviour. I'm not yet convinced that a property is warranted here. It feels like something of an edge case (having Apache's HTTP client on the classpath but not wanting to use it), and, as you have noted, we already have RestTemplateCustomizer available to tune the builder without losing any of its existing auto-configuration. Let's see what the rest of the team thinks.

[ttddyy]

Hi @wilkinsona and other readers :)

The detailed our case was that those apps use multiple RestTemplates. To access external resources, it enables connection-pool and for some of the internal access disables connection-pool. That's why http-client is on the path, but want to configure not to use it.

In terms of the suggesting property, it does not really solve our problem by itself, but was more like a sugar for toggling the auto-detection feature.
Currently, only way of disabling the auto-detection is to programmatically configure the feature via RestTemplateBuilder or RestTemplateCustomizer. The suggestion is to provide non-programmatic way of toggling auto-detection. So that we can disable them by default in application level, and apps/beans that need to use connection-pool can explicitly add such settings - "enables by default and explicit disabling" vs "disable by default and explicit enabling" in application level.

[wilkinsona]

We've discussed this today and decided against adding a property for this. Our recommendation is that you define a RestTemplateCustomizer instead. Thanks anyway for the suggestion.

[mcoware]

Hi All,

Just to elaborate on why do we have Apache's HTTP client while typically not wanting to use it.

• On one hand, we need PATCH support for some specific operations.
• On the other hand, the PoolingHttpClientConnectionManager that comes with Apache's HTTP client can be problematic since forces us to come-up with good sizing numbers (default of 2 concurrent connections per route turn to be a big bottleneck). Also in K8 environments with a lot of pods going up and down it is not yet clear yet if the pooling will benefit us or can bite us further...

In the end, we would have been perfectly fine to stick to the default RestTemplate client but given the absence of PATCH support we had to add Apache's HTTP client. After that point, it turned-out to be harder than we thought to control what's using what.