JacksonAutoConfiguration wipes out modules registered in Jackson2ObjectMapperBuilderCustomizers with higher precedence

[hesselapplications]

If I provide a Jackson2ObjectMapperBuilderCustomizer with @Order(Ordered.HIGHEST_PRECEDENCE) it gets applied before the boot default customizer in JacksonAutoConfiguration. This is to be expected. What is not expected however is that the boot customizer wipes out any modules registered by higher precedence customizers.

Believe the fix is to update this line to use the consumer variant introduced here

I am using boot 3.1.8
Thanks for everything you do.

[wilkinsona]

Thanks, @hesselapplications.

Our customizer is intentionally ordered at 0 to allow other customisers to be ordered either before or after it. I think you could avoid your problem by giving your customizer a lower precedence (any value greater than zero).

It's possible, although perhaps unlikely, that someone may be relying on the current behavior. If we switched to using the additive variant they may end up with Jackson using unwanted modules. As such, I think we may need to wait until 3.3 to make any changes here to avoid a potentially breaking change in a maintenance release.

Out of interest, and to help us to understand how much of a problem this is for you, do you need to be able to configure the modules programatically or could you define them as beans so that the standard customizer registers them all?

[hesselapplications]

could avoid your problem by giving your customizer a lower precedence

Yes additive modules do behave correctly with this approach

Out of interest...

Our use case is we have an organization wide library included in every service. Within that we want to provide some org wide de/serialization defaults and custom modules via a customizer. We want the standard spring customizer to run after that so that the services can provide their own customizations on top of the org defaults in standard spring fashion. That way they are none the wiser to what is happening in the org library, no need to define their customizers at order library customizer + 1

I believe you are right that registering the modules as beans would allow our use case to work though. Thank you for the suggestion

[mhalbritter]

Superseded by #42836.