JsonMapper.Builder cannot be auto-configured with a custom JsonFactory

[mhewedy]

Background

With the migration to Jackson 3.0 in Spring Boot 4, the JsonMapper.Builder has become the primary way to configure the mapper. Unlike Jackson 2.x, Jackson 3.0 emphasizes immutability; specifically, the TokenStreamFactory (e.g., JsonFactory) must be provided at the time the Builder is instantiated.

Current Behavior
In JacksonAutoConfiguration, the JsonMapper.Builder bean is currently initialized using the no-args constructor:

// JacksonAutoConfiguration.java
@Bean
@Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
@ConditionalOnMissingBean
JsonMapper.Builder jsonMapperBuilder(List<JsonMapperBuilderCustomizer> customizers) {
    JsonMapper.Builder builder = JsonMapper.builder(); // Uses default JsonFactory
    customize(builder, customizers);
    return builder;
}

The Problem
Because JsonMapper.builder() is hardcoded to use a default factory, there is no way to provide a custom JsonFactory (configured with CharacterEscapes for XSS protection, for example) without overriding the entire JsonMapper.Builder bean.

Overriding the builder bean is high-friction because it requires the developer to manually replicate the logic that applies the List<JsonMapperBuilderCustomizer>, effectively "detaching" from the standard Spring Boot auto-configuration flow just to change a low-level factory setting.

Proposed Solution
Extract the JsonFactory into its own @Bean and inject it into the builder. This allows users to simply override the JsonFactory bean while keeping the rest of the auto-configuration intact.

@Bean
@ConditionalOnMissingBean
JsonFactory jsonFactory() {
    return JsonFactory.builder().build();
}

@Bean
@Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
@ConditionalOnMissingBean
JsonMapper.Builder jsonMapperBuilder(JsonFactory jsonFactory, List<JsonMapperBuilderCustomizer> customizers) {
    // Injecting the factory into the builder at construction time
    JsonMapper.Builder builder = JsonMapper.builder(jsonFactory);
    customize(builder, customizers);
    return builder;
}

This change would significantly improve extensibility for security-focused configurations (like CharacterEscapes) in the Jackson 3.0 ecosystem.

I can submit a PR

[snicoll]

Rather than exposing a JsonFactory bean for this purpose, I think ObjectProvider<JsonFactory> could be a better option. However, we're tying ourselves with the Jackson API quite a bit by doing this. If Jackson decides to create the builder in different ways in the future, we'll be stuck. I also wonder if Jackson couldn't be improved to avoid this indirection. Have you considered reporting that to them?

[mhewedy]

Dear @snicoll

Thank you for the feedback. I agree that using ObjectProvider<JsonFactory> is a much better and more idiomatic Spring Boot approach. It provides the necessary extensibility while remaining optional, which avoids polluting the context for users who don't need it.

Regarding the concern about tying to the Jackson API: I completely understand the desire to avoid workarounds for upstream design choices. However, since Jackson 3.0 has already moved to this immutable pattern, developers are currently stuck with a 'binary choice' between using Spring auto-configuration or having security features like CharacterEscapes.

I will follow your suggestion and open a ticket (FasterXML/jackson-databind#5524) with the Jackson team regarding the Hard-wired TokenStreamFactory in JsonMapper.Builder(requesting a way to reconfigure or swap the factory on an existing builder). That said, I believe we should move forward with the ObjectProvider implementation in Spring Boot now to provide a bridge for users, as a change in Jackson's core architecture may take significant time to materialize.

What do you think?

[pjfanning]

If Jackson decides to create the builder in different ways in the future, we'll be stuck.

Why do you think Jackson will abandon its new APIs? Jackson 3 took years of work to come out. Pretty unlikely that we will be releasing a completely retooled Jackson any time in the near future.

[snicoll]

I think we should wait and see the outcome of the issue you have created (thanks for that!).

I don't think there's any rush on our side as you can always create your own bean and ours is 3 lines of code.

[snicoll]

If Jackson decides to create the builder in different ways in the future, we'll be stuck.

Why do you think Jackson will abandon its new APIs? Jackson 3 tooks years of work to come out. Pretty unlikely that we will be releasing a completely retooled Jackson any time in the near future.

Do not worry. I don't make any assumptions and there's no rush. We can wait on a reply from the Jackson team and revisit the ask accordingly.

[snicoll]

Looks like that's not going to happen on the Jackson side of things. I am going to flag this to see what the rest of the team thinks of adding the option.