Skip to content

Support ClientHttpMessageConvertersCustomizer in FeignHttpMessageConverters for Spring Boot 4.0 Alignment #1293

@alihsan-tsdln

Description

@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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions