@JsonIgnoreProperties on a property is supposed to ignore "the union of all ignorals" - how?

[da...@bakins-bits.com]

Javadoc for @JsonIgnoreProperties here says "Starting with 2.0, this annotation can be applied both to classes and to properties. If used for both, actual set will be union of all ignorals: that is, you can only add properties to ignore, not remove or override. So you can not remove properties to ignore using per-property annotation."

I can't get this to work in the case where an (abstract) base class has a

@JsonIgnoreProperties(value = { "baseProperty" }, allowGetters = true)

and the subclass has a

@JsonIgnoreProperties(value = { "subclassProperty" }, allowGetters = true)

 

whether that latter annotation on the subclass is on the class or on the getCookie method.

 

In both cases I get an exception

 

Unrecognized field "subclassProperty" (class ...), not marked as ignorable (...)

 

I looked in the jackson-databind tests (where the tests for @JsonIgnoreProperties are) but didn't find a test where it was on a class and a subclass' property.  But maybe I missed it.  Can I get an example?

 

Thanks! -- David

 

 

[Tatu Saloranta]

The expected outcome is that if a sub-class defines `@JsonIgnoreProperties`, that is used as the suppression set.

Merging does NOT occur within class hierarchy.

What javadoc tries to say is that if a property (field, method) also has `@JsonIgnoreProperties`, that would be added to set that comes from class annotations.

This means, effectively, that sub-classes must include ignorals from the base class, if those are to be ignored as well.

The reason for merging missing is technical: the way annotations and mix-ins are handled is type-agnostic and produces a flattened set, using inheritance hierarchy for determining precedence. But since is has no knowledge of behavior of annotations (simple override vs possible augmentation), and, more annoyingly, since there is no way to instantiate new annotation values (even if merging could be done for specific set of annotations, knowing properties within to merge), there is no way to create combined sets.

I hope this helps,

-+ Tatu +-

--
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.

[da...@bakins-bits.com]

OK.  I thought from the Javadoc that being able to put it on properties with the "union" feature was a way to finesse the overriding business in the hierarchy (which I had read about in other posts here). 

But then ... I can't find the original issue that explains why you'd want this feature (since if you can alter the class to add the annotation to the property why can't you just modify the annotation already on the class?) - JACKSON-787 - can you point me to it?

-- David

[Tatu Saloranta]

There are at least two use cases as I recall.

First one would be to solve certain cyclic dependency problems, it would be possible to use, say, 'parent' reference, but drop 'children' property of parent. But only for value included as sort of back-reference.

But probably more common is the case where one only controls class definition that has property, but not the class definition of the value of property. So, like:

public class MyType {

    @JsonIgnoreProperties({ "weirdField" })

    public ThirdPartyType value;
}

One could alternatively use mix-in annotations here, although there are benefits to each approach (some like self-containing nature of this usage; others prefer looser coupling of mix-ins).

So: either asymmetric cases, where given type is sometimes to be serialized differently; or to work-around not being able to modify a class definition.

 -+ Tatu +-