Allow ordering of `HttpMessageConverters`s through `WebMvcConfigurer.configureMessageConverters(HttpMessageConverters.Builder)`

[mp911de]

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.

[sdeleuze]

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

[DeepDhamala]

Hi there @mp911de ,

I went through these issues:
spring-projects/spring-boot#43143
#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?

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

[DeepDhamala]

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

[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!