Open jimirocks opened 3 years ago
Update, the problem only occurs with defaultUseWrapper(false)
and the most probably is caused by
Here it is expected the JsonParser to be configured is either one passed as argument or the delegate one, however, in this scenario JsonParserSequence
is passed which is changing the delegate when iterating through nextToken
.
I guess other place for this configuration must be found, however it's beyond my knowledge
And moreover this BUG deosn't happen, when the type determining property is the first one (therefore JsonParserSequence is not used).
The problem is almost certainly due to buffering, then, necessary often when order of properties does not match what @JsonCreator
needs: parser sequence is used, but mostly the issue is that TokenBuffer
usage: XML deserialization code requires XML-specific parser and TokenBuffer is not one.
I hope this can be addressed in 2.13 as there is a plan to allow format-specific TokenBuffer
sub-classes. That alone is not enough, but might allow a fix with xml-specific variant.
Using the latest
2.12.2
version. Gettingcom.fasterxml.jackson.databind.exc.InvalidDefinitionException: No fallback setter/field defined for creator property 'ListItem' (through reference chain: cz.smarteon.loxone.system.status.Child["ListItem"])
when parent's@JsonTypeInfo(visible = true)
.So it seems it's not possible to have the
type
property visible, while using collections in subtypes.I also have more complex scenario, where the deserialization doesn't fail, but the list in subtype is simply not filled (which is even worse). However I wasn't able to make it short enough to include it in report, instead I found this. This could be also related to #426 ? (just a wild guess)