QName Deserializer

[vitorpamplona]

QName is a special case of an XML Deserializer. This PR parses the contents of the QName and assigns the correct namespace from the XML stack. This mimics the behavior of JAXB parsers.

An XML like this:

<parent xmlns:t="urn:example:types:r1">
    <level1 name="t:DateTime" />"
</parent>";

Should automatically generate a parent.level1.name as QName("urn:example:types:r1", "DateTime", "t")

[cowtowncoder]

This won't work if content is buffered (with TokenBuffer), so I am not sure this approach is valid unfortunately.

[vitorpamplona]

Humm.. interesting.. do you have a simple test case for the Buffered use case?

I am using the same design in our solution so, even if it is not a viable solution here, I would love to improve the code in our solution. Or at least know em when exactly it will fail.

[cowtowncoder]

It's a side-effect of processing, not a feature to enable: if you create a POJO with @JsonCreator(mode = JsonCreator.Mode.PROPERTIES), property values will likely be buffered. Similarly for polymorphic types if Type Id is not the first value deserialized.
Basically any case where stream-order is not the same as the order in which values are needed will be buffered.

[vitorpamplona]

So, the correct way to solve this would be to change the token streams to include namespaces and prefixes available at each one of them?

[cowtowncoder]

Yes. TokenBuffer, however, is not XML specific and cannot (should not) be changed.
2.13 allows replacement of buffer implementation so we could have XmlTokenBuffer sub-class (or such) -- XML backend was the reason to add this -- but there's then the question of how to access information. Probably FromXmlParser and XmlTokenBuffer could implement an interface (to be added) for additional accessors.

I have not, unfortunately, had time to take this approach any further but this would be a very valuable improvement and unblock work on solving multiple issues.
So I would be happy to help you or anybody who had time to look into improvements in this area.

[cowtowncoder]

Ok, first of all: thank you for contributing this patch!
I can see what it is attempting to do and that makes sense.

Unfortunately I am not sure this can be implemented in robust manner: the main problem being that there is no guarantee that

1. There is a Stax parser associated with content -- in particular when buffering (using TokenBuffer) is used (most commonly when @JsonCreator annotated constructor used)
2. Parser itself may not point to actual XML content element (in case of textual content it's probably pointing to closing element, in case of elements)

latter might not be a huge issue as long as namespace resolution context is still available, but former is problematic.
I guess one could make code check accessibility and avoid lookup if parser not available. But that would be hugely confusing since it "sometimes works, sometimes not" (with no obvious signs to user).