Currently, instances of Jackson2ObjectMapperBuilderCustomizer
are only applied to the auto-configured Jackson2ObjectMapperBuilder
. Please give custom beans of Jackson2ObjectMapperBuilder
this same treatment. There may be a valid explanation, but it seems kind of odd that instances of Jackson2ObjectMapperBuilderCustomizer
are not used automatically if you declare your own Jackson2ObjectMapperBuilder
.
In my use case, I need to supply object mapper customization via a library. The logical way to do this would seem to be via Jackson2ObjectMapperBuilderCustomizer
, but this is broken if the library consumer declares its own Jackson2ObjectMapperBuilder
.
And doing this in my library feels kind of hacky:
@Configuration
public class ObjectMapperConfig {
@Autowired
public void configure(ObjectMapper objectMapper) {
<do configuration>
}
}
Comment From: snicoll
Currently, instances of Jackson2ObjectMapperBuilderCustomizer are only applied to the auto-configured Jackson2ObjectMapperBuilder. Please give custom beans of Jackson2ObjectMapperBuilder this same treatment.
Sorry but that doesn't feel right to me. If you define your own builder, you're asking to be in full control of its lifecycle and therefore free to apply customizers in the context, or run some custom logic such as filtering them or not apply them at all.
Comment From: EarthCitizen
@snicoll Just so that it is noted here in case other people have the same need (enterprise-wide object mapper configuration via library), what is the recommended way to configure the object mapper for the application via library since Jackson2ObjectMapperBuilderCustomizer
cannot be reliably used for this purpose?
It seems that Jackson2ObjectMapperBuilderCustomizer
can only be used reliably from the main application itself and not a library, as it would seem reasonable to me that an application could still want to define its own Jackson2ObjectMapperBuilder
while still having an enterprise object mapper configuration auto-applied to its object mappers.
Comment From: snicoll
What we do is no different from what you would do in any enterprise context. You have to settle with one predictable behavior with a well-defined way to take control if need to be. You can create whatever contract that suits you, document it and let library authors use it. As you're using Spring Boot at the application level, the fact that the customizer is not invoked if someone defines their own builder is documented.