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

Allow Jackson configuration through properties #432

Open
snowdrop-bot opened this issue Sep 30, 2021 · 0 comments
Open

Allow Jackson configuration through properties #432

snowdrop-bot opened this issue Sep 30, 2021 · 0 comments

Comments

@snowdrop-bot
Copy link
Collaborator

Description

It would be nice to be able to configure the Jackson ObjectMapper through properties rather than having to create a class extending ObjectMapperCustomizer.

Rather than having to constantly map Quarkus-specific properties to Jackson properties, just allow free-form mapping within the properties that would "flow-through" to the underlying Jackson enum properties. Something like this:

Enum Property Values
com.fasterxml.jackson.databind.DeserializationFeature quarkus.jackson.deserialization.<feature_name> true, false
com.fasterxml.jackson.databind.SerializationFeature quarkus.jackson.serialization.<feature_name> true, false
com.fasterxml.jackson.databind.MapperFeature quarkus.jackson.mapper.<feature_name> true, false
com.fasterxml.jackson.core.JsonGenerator.Feature quarkus.jackson.generator.<feature_name> true, false
com.fasterxml.jackson.core.JsonParser.Feature quarkus.jackson.parser.<feature_name> true, false
com.fasterxml.jackson.annotation.JsonInclude.Include quarkus.jackson.default-property-inclusion always, non_null, non_absent, non_default, non_empty

This way, if/as new "things" are added to the enums, there isn't any work that needs to be done in the extension. As long as <feature_name> aligns with the enum constant, it would just map.

I would envision these properties would be fixed at build time and not overridable at runtime. We'd have to decide what to do in the case that an application provides an ObjectMapperCustomizer and there are properties set. I would think that we would union the properties and what is defined in the ObjectMapperCustomizer. We'd have to figure out "who wins" in the situation where a property is set to one value and the customizer sets a different value for the same enum property. Don't property values specified in application.properties/application.yml always "win" over whats in the code?

Just a side note, I did get this idea from Spring and the Spring documentation which allows for this. Its a very convenient feature to have that eliminates the need to write code.


quarkusio#18572


$upstream:18572$

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants