Testing for a MixIn containing unknown properties.

61 views
Skip to first unread message

Stephen Murby

unread,
Aug 25, 2017, 3:40:16 PM8/25/17
to jackson-user
I have just implemented some read only fields on an api using MixIn to enforce the rename and also the ignore on deserialisation. Like this

@JsonProperty(access = JsonProperty.Access.READ_ONLY, value = "_privateProperty")

The reason that I chose a MixIn was that the POJO is imported from a a different project (a standard model across multiple applications), and this appeared to be the most simple way of changing the serialisation/deserialisation. Since I have an abstract class containing a definition of a number of fields, annotated with this read_only property and a rename, but no other code I have come to see it somewhat as configuration code.

I have a question about testing my configuration though, if I make a typo in the MixIn definition, and so call my property
_pirvateProperty

for example, this will obviously not affect the serialisation of my object with a correctly named field. Is there any way that I can make my application fail to start because of my defining a JsonProperty override for a field that does not exist on the POJO?


Thanks,
Stephen

Tatu Saloranta

unread,
Aug 25, 2017, 3:47:01 PM8/25/17
to jackson-user
If I understand the question correctly answer is no -- mix-in binding
occurs as a step before trying to access merged annotations and
non-matching mix-in annotations are just ignored.
It might be reasonable to have a setting that would error out for
non-matching mixins (field or method) but this does not yet exist.

On mix-in itself: another way to annotate would be to use
`@JsonIgnoreProperties` with `allowSetters = true`. But I don't think
that would help here;
it too could have mis-spelling, and does not allow renaming.

Now that I am thinking, there actually might be something to do if you
had accessor (setter) instead of field. Mix-in classes/interfaces are
allowed to extend/implement
other classes, and if it was possible for interface/class to extend
something and use `@Overrides` compiler could catch one class of
misnaming (of method).
It does not seem like this would directly work with fields however.

-+ Tatu +-


>
>
> Thanks,
> Stephen
>
> --
> You received this message because you are subscribed to the Google Groups
> "jackson-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jackson-user...@googlegroups.com.
> To post to this group, send email to jackso...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages