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:
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.
Description
It would be nice to be able to configure the Jackson
ObjectMapperthrough properties rather than having to create a class extendingObjectMapperCustomizer.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:
com.fasterxml.jackson.databind.DeserializationFeaturequarkus.jackson.deserialization.<feature_name>true,falsecom.fasterxml.jackson.databind.SerializationFeaturequarkus.jackson.serialization.<feature_name>true,falsecom.fasterxml.jackson.databind.MapperFeaturequarkus.jackson.mapper.<feature_name>true,falsecom.fasterxml.jackson.core.JsonGenerator.Featurequarkus.jackson.generator.<feature_name>true,falsecom.fasterxml.jackson.core.JsonParser.Featurequarkus.jackson.parser.<feature_name>true,falsecom.fasterxml.jackson.annotation.JsonInclude.Includequarkus.jackson.default-property-inclusionalways,non_null,non_absent,non_default,non_emptyThis 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
ObjectMapperCustomizerand there are properties set. I would think that we would union the properties and what is defined in theObjectMapperCustomizer. 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 inapplication.properties/application.ymlalways "win" over whats in the code?https://github.com/quarkusio/quarkus/issues/18572
$upstream:18572$