Document HttpMessageConverters detection changes in 4.0.1

[gurpreetsingh85]

Problem

With the 4.0.1-SNAPSHOT build, if a custom JacksonJsonHttpMessageConverter bean is declared and the controller returns ResponseEntity<String> instead of ResponseEntity<?>, the framework will escape an already created JSON string response.

I have added a sample with both 4.0.0 and 4.0.1-SNAPSHOT versions.

With 4.0.0 it returns a valid json as {"Hello": "World"} but with 4.0.1-SNAPSHOT the response becomes "{\"Hello\":\"World\"}"

spring-boot-4-0-0.zip
spring-boot-4-0-1.zip

[philwebb]

Thanks for the sample applications. A bit of debugging shows that in the 4.0.1 SNAPSHOT there's a JacksonJsonHttpMessageConverter at the top of the converter list that isn't in the same location in 4.0.0.

I think the cause is commit 50f64f9 for #48310. Before that commit the supportsMediaType method for the JacksonJsonHttpMessageConverter would be used to add the converter using withJsonConverter. The new code adds it using addCustomConverter and that results in the different ordering.

[bclozel]

Hello @gurpreetsingh85 and thanks for raising this.

This is unfortunately a post-release fix we needed to apply and that can break existing behavior. Commit 50f64f9 explains quite well the situation and why the previous behavior is broken: if a message converter is contributed to the application context, we cannot assume that it's for server, client or both. Also, specific converters can also be applied only in some situations of for specific types, and we cannot infer that with heuristics at startup time.

Updating your application with the following works. This also give you the freedom to only apply it to the server side, or you can choose to also have a ClientHttpMessageConvertersCustomizer that does the same.

    @Bean
    public ServerHttpMessageConvertersCustomizer jacksonServerConverterCustomizer() {
        return (httpMessageConverters) -> {
            httpMessageConverters.withJsonConverter(new JacksonJsonHttpMessageConverter(new JsonMapper()));
        };
    }

I realize that the situation is not ideal because the documentation is not highlighting that "common" converters should be also contributed like that, through a customizer. I'll repurpose this issue.

I'm also thinking that we could provide an HttpMessageConvertersCustomizer contract that would contribute to both client and server, to avoid duplication in case you want the converter to be on both client and server infrastructure. I'll create another issue for that purpose.