One of the cases in #32338 relates to MockRestServiceServer setting a mock request factory on RestClient.Builder. If that same builder is then passed into an application component that wants to customize the request factory (related to production), it ends up replacing the mock request factory.
It's reasonable to assume that if a RestClient.Builder is passed into MockRestServiceServer then the changes to the request factory should stick, and any further changes can be a no-op.
Comment From: rstoyanchev
On closer look, MockRestServiceServer can't prevent the request factory from being replaced.
Looking back at https://github.com/spring-projects/spring-boot/issues/38832 the goal was to make a global switch from HttpURLConnection to JDK HttpClient, but using the most narrow approach for customization. Therefore the recommendation in https://github.com/spring-projects/spring-boot/issues/38832#issuecomment-1861700762 to use a RestClientCustomizer is the more appropriate way to do it for a start.
This case is also very specifically linked to making a choice between two out-of-the-box options in the JDK, and should not be an issue for other client libraries where classpath detection should work fine.
That said the issue was closed in favor of https://github.com/spring-projects/spring-boot/issues/36266 and as of 3.4 there is a first-class way to select the request factory at the earliest point of initialization through an application property:
spring.http.client.factory=jdk