Support `ClientHttpMessageConvertersCustomizer` in `FeignHttpMessageConverters` for Spring Boot 4.0 Alignment

[alihsan-tsdln]

Is your feature request related to a problem? Please describe.
With the architectural changes in Spring Boot 4.0 (as detailed in spring-projects/spring-boot#48310), the configuration of HTTP Message Converters has shifted from collecting all HttpMessageConverter beans from the context to using dedicated customizers (ClientHttpMessageConvertersCustomizer for clients and ServerHttpMessageConvertersCustomizer for servers).

Currently, FeignHttpMessageConverters in Spring Cloud OpenFeign constructs the converter list by collecting raw HttpMessageConverter<?> beans from the ObjectProvider and applying its own Feign-specific org.springframework.cloud.openfeign.support.HttpMessageConverterCustomizer.

This creates an inconsistency in the ecosystem. If I configure a converter using the standard Spring Boot 4.0 ClientHttpMessageConvertersCustomizer (intended for RestClient and RestTemplate), OpenFeign ignores it. I am forced to either:

1. Define the converter as a raw @Bean (which Spring Boot 4.0 discourages for auto-configuration context pollution).
2. Duplicate the configuration using the Feign-specific HttpMessageConverterCustomizer.

Describe the solution you'd like
FeignHttpMessageConverters should detect and apply ClientHttpMessageConvertersCustomizer beans from the application context. This would allow a single point of configuration for all HTTP clients (Feign, RestClient, and RestTemplate) in a Spring Boot 4.0 application.

In FeignHttpMessageConverters.java, specifically within the initConvertersIfRequired() method, the logic builds an HttpMessageConverters instance using HttpMessageConverters.ClientBuilder. Since ClientHttpMessageConvertersCustomizer is designed to customize HttpMessageConverters, it seems natural to apply these customizers there.

Proposed logic change conceptually:

public class FeignHttpMessageConverters {
    
    // Inject ClientHttpMessageConvertersCustomizer provider
    private final ObjectProvider<ClientHttpMessageConvertersCustomizer> clientCustomizers;

    // ... constructor ...

    private void initConvertersIfRequired() {
       if (this.converters == null) {
          // ... existing builder logic ...
          
          HttpMessageConverters hmc = builder.build();
          
          // PROPOSED CHANGE: Apply Spring Boot Client Customizers
          if (this.clientCustomizers != null) {
              this.clientCustomizers.orderedStream().forEach(customizer -> customizer.customize(hmc));
          }

          // Continue with existing logic
          hmc.forEach(converter -> converters.add(converter));
          customizers.forEach(customizer -> customizer.accept(this.converters));
       }
    }
}

Describe alternatives you've considered

• Current Workaround: Defining a separate @Bean for org.springframework.cloud.openfeign.support.HttpMessageConverterCustomizer that duplicates the logic present in my ClientHttpMessageConvertersCustomizer.
• Global Bean: Defining the converter as a global @Bean marked with @Primary. However, as mentioned in the linked Spring Boot issue, relying on collecting beans from the context is being revisited and might not be the preferred way forward for separate client/server configurations.

Additional context
References:

• Spring Boot Issue: Revisit HttpMessageConverters auto-configuration #48310
• Current implementation of FeignHttpMessageConverters relies on:

  public FeignHttpMessageConverters(ObjectProvider<HttpMessageConverter<?>> messageConverters,
        ObjectProvider<HttpMessageConverterCustomizer> customizers) {
     this.messageConverters = messageConverters;
     this.customizers = customizers;
  }

  It misses the ClientHttpMessageConvertersCustomizer which is now the standard for client-side configuration in Boot 4.

[markusjevringflowers]

@alihsan-tsdln how would you use the HttpMessageConverterCustomizer in your work-around if the JsonMapper in spring-boot 4 and jackson 3 is immutable?

[SatishTelaprolu]

I believe the suggested change here is already addressed and included as part of the bug fix in ##1257
That PR was merged and the fix is available in the released path v5.0.1

[dulciscrustulam]

Hello there!
Despite the fact some gap has been fixed in 5.0.1, I've faced one more issue today that highly likely is related to the issue raised.

The project is on spring-cloud-openfeign 5.0.1 with Spring Boot 4.0.2. Feign still uses a different JSON mapper than the rest of the app, so the Jackson config (e.g. naming strategy) is not applied when Feign decodes responses.

In my case, Feign deserialises a JSON response (snake_case) into a type that uses a class-level naming strategy so snake_case maps to camelCase. The fields end up null because the naming strategy is not applied. In the debugger I see the response is decoded by JacksonJsonHttpMessageConverter with a JsonMapper (Jackson 3) instance that is not the application's configured mapper. Adding explicit @ JsonProperty ("snake_case_name") on the affected fields fixes the mapping, so the issue is with Feign's decoder/mapper, not the API payload.

Just to recreate, project's Feign client is declared with a @JsonNaming(PropertyNamingStrategies.SnakeCaseStrategy.class) from jackson-databind:2.21.0. I suspect that in this setup the client gets its own context and does not receive the same HttpMessageConverters built via ClientHttpMessageConvertersCustomizer, so it still uses a default JsonMapper without Jackson settings (e.g. naming strategy).

Thanks

[user790235692]

Hello, any update on this issue ?