Support throwing `MismatchedInputException` when deserializing properties that are not part of the view

[sebdotv]

Using a deserialization view and DeserializationFeature.FAIL_ON_IGNORED_PROPERTIES, it could be convenient if an error was raised when attempting to deserialize a property that is not part of the view.

In the following example code, the property annotatedWithView2 (which is not part of the deserialization view, View1) is correctly ignored during deserialization, but no error is raised.

This could be seen as an extension of #343 for views.

    interface View1 { }
    interface View2 { }

    static class T {
        public Long unannotated;
        @JsonView(View1.class)
        public Long annotatedWithView1;
        @JsonView(View2.class)
        public Long annotatedWithView2;
    }

    public static void main(String[] args) throws IOException {
        T t = new ObjectMapper()
            .enable(DeserializationFeature.FAIL_ON_IGNORED_PROPERTIES)
            .readerWithView(View1.class)
            .withType(T.class)
            .readValue("{ \"unannotated\":1, \"annotatedWithView1\":1, \"annotatedWithView2\":1 }");

        System.out.println(t.unannotated + " " + t.annotatedWithView1 + " " + t.annotatedWithView2);
    }

[cowtowncoder]

Ok. I think I understand the request. Will need to see how easy this would be to implement.
Also wondering what the backwards compatibility constraints are (that is, would this handling need to be behind an on/off feature), given that it would make previously working cases fail.

[sebdotv]

Maybe the semantics of the DeserializationFeature.FAIL_ON_IGNORED_PROPERTIES optin is large enough to cover the case already? Would need feedback from actual deserialization view users, which I'm not yet.

[cowtowncoder]

Yes, semantics could cover, but behavioral changes are always risky.

[davideanderson]

I just ran into this myself. For what it is worth, I believe this would be the place to do the test and throw

com.fasterxml.jackson.databind.deser.BeanDeserializer#deserializeWithView:

                if (!prop.visibleInView(activeView)) {
                    jp.skipChildren();
                    continue;
                }

So, rather than simply skipping children and continuing, test the configuration and throw if appropriate.

[cowtowncoder]

@davideanderson thank you; this should help in figuring out how to make it work; sounds like there'd be all access needed to see what should be the action.

[cowtowncoder]

Hmmh. Just realized something: number of DeserializationFeatures has grown rapidly and there are some relevant limits to consider. So will have to take my time to consider how this should actually be integrated...

[simontb]

I think the place that @davideanderson pointed out is appropriate and jp.skipChildren(); could be replaced with handleUnknownProperty(p, ctxt, bean, propName);.

@cowtowncoder I get your point, that this could break working code, but since I see this as a bug, I think it's okay to make this change without introducing a new DeserializationFeature like FAIL_ON_DISABLED_BY_VIEW. Otherwise the call to handleUnknownProperty would need to be toggled by this feature.