spring.mvc.converters.preferred-json-mapper is effectively ignored when certain serde frameworks are detected in the classpath, notably kotlinx.serialization about spring-boot

[wilkinsona]

Using the postProcess hooks points offers more precise control over the end result. Perhaps not needed here, but it's the recommended approach and this sort of situation is why those methods were introduced.

[wilkinsona]

Until we find time to look at this in detail, as an alternative workaround, you may want to consider defining your own HttpMessageConverters bean that overrides postProcessConverters and postProcessPartConverters to filter out the unwanted converter.

[volkert-fastned]

@wilkinsona Thanks for the alternative workaround. Can you maybe explain what the advantage of that approach is over the workaround I shared above?

[volkert-fastned]

@wilkinsona Thanks! By the way, when I have overridden postProcessConverters(), I don't also have to override postProcessPartConverters(), correct? The latter only applies in a subset of cases, do I interpret that correctly from the code?

Based on the example you linked to, I ended up with this (in Kotlin), which indeed works as well, at least in our case:

import org.springframework.boot.autoconfigure.http.HttpMessageConverters
import org.springframework.context.annotation.Bean
import org.springframework.context.annotation.Configuration
import org.springframework.http.converter.AbstractKotlinSerializationHttpMessageConverter
import org.springframework.http.converter.HttpMessageConverter

@Configuration
class MessageConvertersConfig {
    /**
     * Bean provider that filters out standard [HttpMessageConverter]s that we don't want Spring to use, even when the
     * serde frameworks for them are detected by Spring in the classpath.
     *
     * With thanks to https://github.com/spring-projects/spring-boot/issues/39853#issuecomment-1984360351 and
     * https://github.com/spring-projects/spring-boot/issues/1482#issuecomment-61862787
     *
     * Should override [org.springframework.boot.autoconfigure.http.HttpMessageConvertersAutoConfiguration.messageConverters]
     */
    @Bean
    fun filteredMessageConverters(): HttpMessageConverters =
        object : HttpMessageConverters() {
            override fun postProcessConverters(converters: MutableList<HttpMessageConverter<*>>): MutableList<HttpMessageConverter<*>> {
                converters.removeIf {
                    it is AbstractKotlinSerializationHttpMessageConverter<*>
                }

                return converters
            }
        }
}

[wilkinsona]

By the way, when I have overridden postProcessConverters(), I don't also have to override postProcessPartConverters(), correct? The latter only applies in a subset of cases, do I interpret that correctly from the code?

Yes, that's right. postProcessPartConverters() only applies to the converters that are used by AllEncompassingFormHttpMessageConverter. If your app isn't receiving multi-part requests, the converters used by this converter converter won't need to be customized.

Just to make sure I have understood your situation correctly, am I right in understanding that:

1. Your application has Jackson on the classpath
2. Your application has kotlinx.serialization on the classpath
3. You are (de)serializing a type that kotlinx.serialization supports (kotlinx.serialization.SerializersKt.serializerOrNull returns a KSerializer for the type) but you want Jackson to be used instead

Assuming that the above is correct, is kotlinx.serialization on the classpath for some other reason or is it there accidentally? Just trying to understand the scope of the problem and gauge how likely others are to be affected by it – this is the first time it's been raised in Boot's issues as far as I can remember.