You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
ObjectMapper
through 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.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 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.yml
always "win" over whats in the code?quarkusio#18572
The text was updated successfully, but these errors were encountered: