Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify why @Primary is recommended when defining your own ObjectMapper that replaces JacksonAutoConfiguration's #42598

Closed
pratyakshajha opened this issue Oct 11, 2024 · 1 comment
Labels
type: documentation A documentation update
Milestone

Comments

@pratyakshajha
Copy link

The JacksonAutoConfiguration class takes care of creating a default ObjectMapper bean. The conditions based on which this configuration gets applied can be documented in a better way. For example, Spring docs link is confusing. As per this, both @Bean and @Primary are needed to replace the default ObjectMapper:
image
In reality, the @Primary is not necessary, just creating a ObjectMapper bean results in the default jackson ObjectMapper bean not being created. This can result in problems as described in #22403.

This behaviour should be mentioned clearly in the documentation. Also, the Javadoc for JacksonAutoConfiguration states this behaviour and this clarity should be present in the documentation as well.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Oct 11, 2024
@pratyakshajha pratyakshajha changed the title Imporove documentation related to JacksonAutoConfiguration Improve documentation related to JacksonAutoConfiguration Oct 11, 2024
@wilkinsona wilkinsona changed the title Improve documentation related to JacksonAutoConfiguration Clarify why @Primary is recommended when defining your own ObjectMapper that replaces JacksonAutoConfiguration's Oct 11, 2024
@wilkinsona
Copy link
Member

Annotating the @Bean method with @Primary is recommended by the documentation as the auto-configured ObjectMapper is @Primary. In other words, if you want your custom ObjectMapper to be a drop-in replacement for the auto-configuration's, it should be @Primary. This allows it to be the preferred choice when there are multiple ObjectMapper beans in the context as is quite often the case.

We can update the docs to try to make this more clear.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: documentation A documentation update
Projects
None yet
Development

No branches or pull requests

3 participants