`XmlMapper`/`UntypedObjectDeserializer` swallows duplicated elements in XML documents

[joaovarandas]

Hello guys.

I think I have already seen this issue around, but, for UntypedObjectDeserializer the solution maybe a bit different.

Entity

<?xml version="1.0" encoding="UTF-8"?>
<person>
   <name>John</name>
   <parent>Jose</parent>
   <parent>Maria</parent>
   <dogs>
      <count>3</count>
      <dog>
         <name>Spike</name>
         <age>12</age>
      </dog>
      <dog>
         <name>Brutus</name>
         <age>9</age>
      </dog>
      <dog>
         <name>Bob</name>
         <age>14</age>
      </dog>
   </dogs>
</person>

Code

new XmlMapper().readValue(xml, Object.class);       

Output

{
  "name" : "John",
  "parent" : "Maria",
  "dogs" : {
    "count" : "3",
    "dog" : {
      "name" : "Bob",
      "age" : "14"
    }
  }
}

Problem

Duplicated elements in the entity get swallowed by current UntypedObjectDeserializer implementation.

I can't use Typed Objects. In my use case, I don't have any typed objects, because I don't know how objects are sent to me.

Possible Solution

While creating the Map for the data, check if there are duplicated keys, and start an Array, with this approach, the output would be:

{
  "name" : "John",
  "parent" : [ "Jose", "Maria" ],
  "dogs" : {
    "count" : "3",
    "dog" : [ {
      "name" : "Spike",
      "age" : "12"
    }, {
      "name" : "Brutus",
      "age" : "9"
    }, {
      "name" : "Bob",
      "age" : "14"
    } ]
  }
}

How to Reproduce

Gist

• https://gist.github.com/joaovarandas/1543e792ed6204f0cf5fe860cb7d58ed

Artifacts:

• jackson-core
• jackson-databind
• jackson-dataformat-xml

Version:

• 2.7.4

Conclusion

The gist implements the solution using an extended version of the UntypedObjectDeserializer.

If not the default behavior, what about creating a new DeserializationFeature to enable this(default or not)?

Should you guys like/aprove this solution, I can always fork the project and submit a pull request with the full solution as a feature or default behavior.

Thanks!
Jp

[joaovarandas]

The new test 'testDuplicatedElementsSwallowing' in class 'XmlParserTest' ensures it is working as proposed.

Let me know if you want me to pull this.

[cowtowncoder]

I don't think this should be the default behavior, but I would be fine with a feature that allows doing this.

One question here is regarding how it should be enabled; at least two possibilities:

1. Straight setter/getter in XmlMapper (similar to setDefaultUseWrapper)
2. FromXmlParser.Feature

Of these I would otherwise favor (2) since it's easier to expand, but one problem is that this feature can not be changed on per-call basis and as such should not be a (format-specific) DeserializationFeature. So perhaps (1) is the better way to go.

Alternatively perhaps it would be better to add option (3); add XmlMapper.Feature.

So if you can do a PR for feature itself (with simple setter, for now), and I can retrofit XmlMapper.Feature?

[joaovarandas]

The problem with adding as a "optional" feature (or setter) is that "unaware" developers could lose data deserialized from XML. That's what happened to me: - Users found out the bug weeks after it has been deployed to production, since during the tests there were no repeated elements.

Anyway, sure I can do that. And it fits my use case as well.
Thanks!

[cowtowncoder]

Another option would be to explicitly fail on any attempt to bind to "untyped" (java.lang.Object), to make it explicitly clear that failure occurs. I am open to doing this, although that would have to go in next minor version. It would probably also have to apply to Map...

In the end I do not think there are good options: ideally XML is not being mapped to either Object or Map. Trying to auto-detect between List of things and single thing does not work well with Java style typing -- access to such values is awkward. In fact, I might go as far as claiming that it might make more sense to use DOM (and alternatives, JDOM, DOM4J) instead of (Jackson) databind.

[joaovarandas]

Yeah... I agree with you, but:

I'm currently building a facade for the Apache Components/HTTPClient, and invoking SOAP services... Then I just "transform" the return object to a simple Map/List, and invoke JavaScript code (using Nashorn).

In that use case, it doesn't matter if the object is an Array or a Map since I access them using simple JavaScript bindings like: data["attribute-key"] or data[0] for an array ...

Probably for Scala or other languages inside JVM it would be the same.

I think failing is good too, to fail when there are duplicated elements in a default UntypedObject deser ...

It's not final yet, but if you wanna take a look at the project:
https://github.com/inpaas/inpaas-httpclient

[joaovarandas]

@cowtowncoder how could I "deregister" a Module or the deserializer?

See the code below:

public XmlMapper setUseXmlUntypedObjectDeserModule(boolean state) {
    if (state == true) {
        Module xmlUntypedObjectDeserModule = new SimpleModule().addDeserializer(Object.class, new XmlUntypedObjectDeserializer());
        registerModule(xmlUntypedObjectDeserModule);
    } else {
        // is there anyway to rollback the state?
    }

    return this;
}

[cowtowncoder]

There is no way to deregister a module, since registration really is just a callback to get a chance to register other things. Further, there is no metadata on what registered any given handler (no back-references to module). So answer is you can not. You can just register more handlers.

So question would rather become "what are you trying to do". It is possible to add suitable Serializers / Deserializers handler to -- for example -- avoid return custom serializer/deserializer depending configuration.

[Paradoxia]

@joaovarandas Thank you, your gist solution saved my day.

[arakelian]

@joaovarandas Saved me, too. Thanks.

[perezmlal]

@joaovarandas thanks, your gist solution works perfect.