FasterXML / jackson-dataformat-xml

Extension for Jackson JSON processor that adds support for serializing POJOs as XML (and deserializing from XML) as an alternative to JSON

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Nesting depth in `XmlReadContext` is not incremented/decremented on JsonToken.START_OBJECT/JsonToken.END_OBJECT

AlexUg opened this issue · comments

This bug can be fixed with below patch (just like it is implemented in 'com.fasterxml.jackson.core.json.JsonReadContext'):

diff --git a/src/main/java/com/fasterxml/jackson/dataformat/xml/deser/XmlReadContext.java b/src/main/java/com/fasterxml/jackson/dataformat/xml/deser/XmlReadContext.java
index bfef7d4d..8c57cfe4 100644
--- a/src/main/java/com/fasterxml/jackson/dataformat/xml/deser/XmlReadContext.java
+++ b/src/main/java/com/fasterxml/jackson/dataformat/xml/deser/XmlReadContext.java
@@ -66,6 +66,7 @@ public final class XmlReadContext
         _lineNr = lineNr;
         _columnNr = colNr;
         _index = -1;
+        _nestingDepth = parent == null ? 0 : parent._nestingDepth + 1;
     }
 
     protected final void reset(int type, int lineNr, int colNr)

Sorry for not creating a pull request...

@AlexUg Thank you for reporting this. Not a problem wrt PR, we can do that (plus specifically need to test this(.

#609 is already open and describes why the nesting depth is not checked in jackson-dataformat-xml. TLDR is Woodstox can do the check.

#609 is already open and describes why the nesting depth is not checked in jackson-dataformat-xml. TLDR is Woodstox can do the check.

The "jackson-dataformat-xml" should not check nesting, but "jackson-dataformat-xml" should provide consumers with correct nesting information, as do the JSON and YAML parsers provided by "FasterXML" (to avoid violating interface specs - users expect correct information by calling 'parser.getParsingContext().getNestingDepth()' regardless of the parser type).

True. There are some complexities here since nesting count will not necessarily be the same for logical content (JsonToken stream) as physical XML tokens -- this because there's a bit of translation going on.
But it should probably be more useful than not having nesting depth at all.

I am also not sure how easy it'd be to implement #609 over doing it on XML module side.

Fixing tracking part as suggested, via #658.