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

[AlexUg]

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

[cowtowncoder]

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

[pjfanning]

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

[AlexUg]

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

[cowtowncoder]

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.

[cowtowncoder]

Fixing tracking part as suggested, via #658.