ProblemDetailJacksonMixin not configured on Jackson JsonMapper

[fbus]

This is a regression from spring boot 4.0.0-M3

Description

DemoApplication.java

I add custom properties to my ProblemDetail errors.

With the sample code attached, on 4.0.0-M3 I get this :

{
  "detail": "Simulated error",
  "instance": "/hello",
  "properties": {
    "customProperty": "Custom Value"
  },
  "status": 400,
  "title": "OH NOOOOO :(",
  "type": null
}

expected result (from 4.0.0-M2)

{
  "title": "OH NOOOOO :(",
  "status": 400,
  "detail": "Simulated error",
  "instance": "/hello",
  "customProperty": "Custom Value"
}

As you can see there is a "properties" node which should not be there

My analysis

HttpMessageConvertersAutoConfiguration creates an HttpMessageConverters instance based on :

1. HttpMessageConverter from the context (additionalConverters)
2. default HttpMessageConverter list

In both cases there is a JacksonJsonHttpMessageConverter, as shown here:

\

The first one (from additionalConverters) takes precedence, and is created by JacksonHttpMessageConvertersConfiguration. It uses the JsonMapper created in JacksonAutoConfiguration
using configuration properties (spring.jackson.* )
It doesn't add support for ProblemDetailJacksonMixin.

On the other hand, the 2nd JacksonJsonHttpMessageConverter created with default constructor adds ProblemDetailJacksonMixin

solution

Well, I'm not sure. Maybe JsonMixinModuleEntries should add the ProblemDetailJacksonMixin if it's found in classpath ? (or handle something with @ConditionalOnClass(ProblemDetailJacksonMixin.class) ?)

[wilkinsona]

@bclozel could this be related to #46411, only appearing now due to Boot upgrading to Jackson 3 in 4.0.0-M3?

[bclozel]

I don't think this is strictly related to #46411, although implementing that one would do some good for the overall alignment with Framework.

With Jackson 2.x, Spring Boot was using Framework's Jackson2ObjectMapperBuilder which registers automatically the ProblemDetail mixins. With Jackson 3.x support, Framework does not ship a builder anymore and cannot apply this opinion - instead, it registers this mixin in JacksonJsonHttpMessageConverter and JacksonJsonEncoder **if no custom JsonMapper is provided.

I think this is an unintended change behind the removal of the Jackson builders in Spring Framework.

There are two ways to solve this:

1. rebuild() the JsonMapper to add the problem details mixing, right before using it in the codec or message converter. This is not acceptable as we would get a different JsonMapper instance and this would not be the bean we contributed in the first place.
2. add a new ProblemDetailsAutoConfiguration in the "spring-boot-webmvc" module that contributes a JsonMapperBuilderCustomizer in order to add this mixin when the spring.mvc.problemdetails.enabled property is true. This arrangement feels a bit odd because we would have to order this autoconfiguration before the JacksonAutoConfiguration, which is two modules away in the dependency chain ("spring-boot-webmvc" -> "spring-boot-http-converter" -> "spring-boot-jackson"). Same applies to the WebFlux variant.

@wilkinsona Do you see any other arrangement that would work here?

[wilkinsona]

Perhaps Boot's Jackson auto-configuration could, when it's on the classpath, always add the ProblemDetailsMixin to the auto-configured JsonMapper. This would give an experience that's similar to Boot 3.x where we used Jackson2ObjectMapperBuilder.