On deserialization consider allowing fields in other views to be considered as unknown properties instead of silently ignoring them

[joca-bt]

Consider the following class

public class Test {
    public String nonViewField;
    @JsonView(View1.class)
    public String view1Field;
    @JsonView(View2.class)
    public String view2Field;
}

When deserializing the following JSON, an error will be raised as potato is an unknown property.

{
  "nonViewField": "value",
  "potato": 1
}

When deserializing the following JSON with View1, I would expect to get a similar error as before, stating view2Field is an unknown property, but instead it simply gets ignored (the field is set to null).

{
  "nonViewField": "value",
  "view1Field": "value",
  "view2Field": "value"
}

I tried enabling FAIL_ON_IGNORED_PROPERTIES but it didn't seem to affect this situation. Is this something that would be possible? Either via FAIL_ON_IGNORED_PROPERTIES or some other configuration?

This is helpful when we want to do versioning on a DTO in a declarative manner, for example.

[cowtowncoder]

I think we would consider a new DeserializationFeature to enable such behavior, if anyone was interested in trying to implement this functionality. I think this makes sense. Default behavior probably cannot be changed due to backwards-compatibility concerns.

[JooHyukKim]

Just stoppying by with naming ideas 😆

• DeserializationFeature.FAIL_ON_UNEXPECTED_VIEW_PROPERTIES
• DeserializationFeature.FAIL_ON_MISMATCHED_VIEW_FIELDS
• DeserializationFeature.STRICT_VIEW_PROPERTY_VALIDATION
• DeserializationFeature.STRICT_VIEW_DESERIALIZATION
• DeserializationFeature.REQUIRE_EXACT_MATCHING_VIEW

[cowtowncoder]

I like the first option!

[JooHyukKim]

@joca-bt PTAL at #4275 if it solves the discusssed problem?

[cowtowncoder]

Ok, so this is dup of #437 so will close, but will be allowed with new DeserializationFeature.FAIL_ON_UNEXPECTED_VIEW_PROPERTIES in 2.17.0.