Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

QName Deserializer #543

Open
wants to merge 2 commits into
base: 2.14
Choose a base branch
from
Open

QName Deserializer #543

wants to merge 2 commits into from

Conversation

vitorpamplona
Copy link

@vitorpamplona vitorpamplona commented Aug 26, 2022

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")

if (qName.getLocalPart().indexOf(":") > 0) {
String prefix = qName.getLocalPart().split(":")[0];
String localPart = qName.getLocalPart().split(":")[1];
String namespace = ((FromXmlParser)ctxt.getParser()).getStaxReader().getNamespaceContext().getNamespaceURI(prefix);
Copy link
Member

@cowtowncoder cowtowncoder Aug 30, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants