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
Is your feature request related to a problem? Please describe.
Every so often, I have a desire to de/serialize the same object differently in different contexts. This can be accomplished today by writing different mixins for each context. Alternatively, if it's just a difference of field inclusion, the @JsonView annotation can be used.
On thing that feels clunky with the mixin approach is that the contextual configuration differences are declared in two different code locations. To figure out how any given field might be serialized, both locations need to be viewed and compared.
Mixins also have to be declared at ObjectMapper creation time, whereas views can be varied per request:
Mixins are difficult to use per-request in the Spring Web framework since it generally assumes a single ObjectMapper and it requires quite a bit of non-obvious cumbersome configuration to support different ObjectMappers for different endpoints. On the other hand, JSON views have first class support:
In summary, while powerful, mixins have a few strikes against them in the usability department. JSON views, on the other hand, only work for property exclusion, and cannot be used for other kinds of serialization differences.
Describe the solution you'd like
It would seem like a group-based mechanism like JsonView that would work for any Jackson configuration annotation would be handy, and would fit well with Jackson, as an alternative to using mixins.
/** Validates a minimal set of constraints */publicinterfaceMinimal {}
publicclassAddress {
@NonEmpty(groups = Minimal.class)
@Size(max=50)
privateStringstreet1;
@NonEmptyprivateStringcity;
@NonEmpty(groups = {Minimal.class, Default.class})
privateStringzipCode;
[...]
}
Usage example
One option would be to add a groups (or group) element to literally every annotation type like Jakarta Bean Validation does, in which case it would look very similar to the above Jakarta Bean Validation example:
publicclassAddress {
@JsonFormat(pattern = "MM/dd/yyyy", groups = ExternalApi1.class)
@JsonFormat(shape = NUMBER, groups = ExternalApi2.class)
@JsonFormat(pattern = "yyyy-MM-dd") // The default if no groupprivateLocalDatemyField;
}
If you didn't want to add groups to every single Jackson annotation, an alternate approach might be to put the annotations inside a dedicated grouping annotation:
@JsonGroup(group = ExternalApi1.class, annotations = {@JsonFormat(pattern = "MM/dd/yyyy")})
@JsonGroup(group = ExternalApi2.class, annotations = {@JsonFormat(shape = NUMBER)})
@JsonFormat(pattern = "yyyy-MM-dd") // The default if no groupprivateLocalDatemyField;
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Every so often, I have a desire to de/serialize the same object differently in different contexts. This can be accomplished today by writing different mixins for each context. Alternatively, if it's just a difference of field inclusion, the
@JsonView
annotation can be used.On thing that feels clunky with the mixin approach is that the contextual configuration differences are declared in two different code locations. To figure out how any given field might be serialized, both locations need to be viewed and compared.
Mixins also have to be declared at
ObjectMapper
creation time, whereas views can be varied per request:Mixins are difficult to use per-request in the Spring Web framework since it generally assumes a single
ObjectMapper
and it requires quite a bit of non-obvious cumbersome configuration to support differentObjectMapper
s for different endpoints. On the other hand, JSON views have first class support:In summary, while powerful, mixins have a few strikes against them in the usability department. JSON views, on the other hand, only work for property exclusion, and cannot be used for other kinds of serialization differences.
Describe the solution you'd like
It would seem like a group-based mechanism like
JsonView
that would work for any Jackson configuration annotation would be handy, and would fit well with Jackson, as an alternative to using mixins.Other annotation-based libraries in the Java ecosystem do similar. The main one that comes to mind is Jakarta Bean Validation with its validation groups:
Usage example
One option would be to add a
groups
(orgroup
) element to literally every annotation type like Jakarta Bean Validation does, in which case it would look very similar to the above Jakarta Bean Validation example:If you didn't want to add
groups
to every single Jackson annotation, an alternate approach might be to put the annotations inside a dedicated grouping annotation:The text was updated successfully, but these errors were encountered: