Spring Allow ordering of HttpMessageConverterss through WebMvcConfigurer.configureMessageConverters(HttpMessageConverters.Builder)

The newly introduced WebMvcConfigurer.configureMessageConverters(HttpMessageConverters.Builder) hook should allow ordering message converters to contribute converters that are used before core (built-in) converters. This was previously possible through the List-based variant configureMessageConverters(List<HttpMessageConverter<?>>) by adding converters using add(index, …).

A use-case is Spring Data's ProjectingJackson2HttpMessageConverter that is able to create JSON projections using annotated interfaces but is not suitable to write payloads to JSON, hence replacing a potentially existing MappingJackson2HttpMessageConverter/JacksonJsonHttpMessageConverter is not an option.

Comment From: sdeleuze

I guess @bclozel will have a look once back from PTO.

Comment From: DeepDhamala

Hi there @mp911de ,

I went through these issues: https://github.com/spring-projects/spring-boot/issues/43143 https://github.com/spring-projects/spring-framework/issues/33894 as well as the related commit code to understand the issue from the beginning.

Now I understand what you were saying — since both configureMessageConverters(List<HttpMessageConverter<?>>)and extendMessageConverters(List<HttpMessageConverter<?>>) are deprecated, we need a new way to control the order of message converters.

How about we do this?

class ServerOrClientClass {

    private final List<HttpMessageConverter<?>> converters = new ArrayList<>();

    void anySetter() {
        HttpMessageConverters.withDefaults()
            .build()
            .forClient()
            .forEach(this.converters::add);

        this.converters.add(3, myCustomConverter); // insert at desired position
    }
}

Here, we can change the index (3) to control the ordering of the converters. Would this approach work with what you’re suggesting?

Comment From: bclozel

@DeepDhamala I think this proposal is quite verbose and still require to use a list-based approach, when the main driver behind this change is to avoid that in the first place.

I'm working on a fix that will add custom converters ahead of the auto-detected ones. This should align with the WebFlux implementation as well as the general approach in Spring Framework regarding resolvers.

Comment From: DeepDhamala

Thanks for the clarification, @bclozel. Excited to see how that gets implemented!

Comment From: bclozel

@mp911de I have fixed this behavior and this should be available shortly in SNAPSHOTs. Just so you know, the API might evolve a bit more because I'm experimenting with changes that would bring this closer to the WebFlux variant. I'll ping you on a new issue if necessary. In all cases, we will retain the ordering of custom vs. auto-detected converters. Thanks for reporting this!