Create UnknownPropertiesTest.java

[pjfanning]

test case for #3721

[cowtowncoder]

Ok so this exhibits the problem: and it reminds me that it is specifically the @JsonCreator that induces the issue here -- and I think with Scala (module) essentially all POJOs (POSOs?) use that handling.

Aside from that, I guess testing/verification here would mean adding breakpoints (etc) in accessor or such -- or just observing time to run?

[pjfanning]

Add a breakpoint in NumberInput.parseBigInteger (both versions of this overloaded method).
Scala norms are to use case classes for JavaBean equivalent use cases but case classes are immutable (by default) - ExtractFieldsNoDefaultConstructor is a Java approximation of how case classes work. Java Records can be said to be inspired by Scala case classes and equivalents in other languages.

[cowtowncoder]

@pjfanning Ah-ha! Ok, yes, now I see it clearly: BeanDeserializer, line 503 or so:

            if (_ignoreAllUnknown) {
                p.skipChildren();
                continue;
            }

but for some reason not otherwise. I think I'll see how many tests break if using this for all cases...

Interesting: exactly TWO tests (only!) fail. One is testing DeserializationProblemHandler (which wouldn't get invoked when we short-circuit), the other is from TestPolymorphicCreators and that's more interesting: it relies on buffering to handle reordered properties. But I am not sure why properties of subtype aren't yet known at the point where buffering occurs...
That one would essentially break for reasons not immediately obvious.

I'll try to find ConfigOverride setting next, to ensure there is an existing way to achive this -- it doesn't mean we couldn't consider a new DeserializationFeature but just want to see if it an alternative exists.

[cowtowncoder]

Ohhhhh. Actually, the test failing in TestPolymorphicCreators is quite interesting: it is NOT using @JsonTypeInfo based polymorphism, but rather manual kind wherein @JsonCreator in super type is used but then when instance is constructed, we actually look for potentially different deserializer (see handlePolymorphic of BeanDeserializer).
That is quite a powerful feature and no doubt used by some developers somewhere.

And all that is required is the use of properties-based creator.

But this also suggests "ignoreUnknown" would break this usage too. Weird.

EDIT: adding @JsonIgnoreProperties(ignoreUnknown = true) does indeed break the test

[cowtowncoder]

Ok, quick note: I may not have explained my ideas clearly, but the lazy/buffered value types must be provided by jackson-core, not create by databind. This because while getting text via JsonParser.getText() works for JSON backend, it is likely going to be pretty bad for binary formats.

But maybe work here could try prototyping approach with easier-to-test approach. Even if eventual implementation would be different and split across components.

[pjfanning]

Ok, quick note: I may not have explained my ideas clearly, but the lazy/buffered value types must be provided by jackson-core, not create by databind. This because while getting text via JsonParser.getText() works for JSON backend, it is likely going to be pretty bad for binary formats.

But maybe work here could try prototyping approach with easier-to-test approach. Even if eventual implementation would be different and split across components.

How about if I move the new Lazy* classes to jackson-core and add getLazyBigIntegerValue() and getLazyDecimalValue() to JsonParser interface?

[cowtowncoder]

Ok, quick note: I may not have explained my ideas clearly, but the lazy/buffered value types must be provided by jackson-core, not create by databind. This because while getting text via JsonParser.getText() works for JSON backend, it is likely going to be pretty bad for binary formats.
But maybe work here could try prototyping approach with easier-to-test approach. Even if eventual implementation would be different and split across components.

How about if I move the new Lazy* classes to jackson-core and add getLazyBigIntegerValue() and getLazyDecimalValue() to JsonParser interface?

That would be better, although I am not sure there should be separate accessors for types, instead of something like getLazyNumber() -- given that caller (TokenBuffer) does not necessarily have same information on actual underlying type (binary formats have strict types; JSON has approximate type, configuration dependant).
It all has to do with call sequence used for buffering.

[pjfanning]

replaced with #3761