XML de-/serialization of collection/array attributes not respecting UseWrapper when using maps

(tested with 2.11.3 and 2.12.0-rc1)

I'm reading dynamic json and xml data using Jackson, so I mostly work with Map<String,Object> instead of POJOs. When converting these maps to/from XML I found some unusual behaviour which I think is a bug. It occurs when the values contained in the map are Collections or Arrays.

To replicate I use a simple POJO which I would suspect to behave very similar to using a Map with a list entry named "myList":

	static class SomePojo {
		public List<String> myList = new ArrayList<>();

		@Override
		public String toString() {
			return "SomePojo[myList=" + String.valueOf(myList) + "]";
		}

	}

Therefore I would expect the xml to look like:

	static final String XML_WITH_WRAPPER = "<daRoot><myList><myList>string1</myList><myList>string2</myList></myList></daRoot>";
	static final String XML_NO_WRAPPER = "<daRoot><myList>string1</myList><myList>string2</myList></daRoot>";

In the unit tests below I further use a simple helper method:

	private static XmlMapper createXmlMapper(boolean useWrapper) {
		XmlMapper om = new XmlMapper();
		om.setDefaultUseWrapper(useWrapper);
		om.enable(SerializationFeature.INDENT_OUTPUT);
		return om;
	}

Testing serialization, the following test fails because the map-version doesn't seem to respect useWrapper:

	@Test
	public void xmlSerializationOfCollectionEntriesInMapsShouldRespectUseWrapper() throws IOException {
		SomePojo pojo = new SomePojo();
		pojo.myList = List.of("string1", "string2");

		Map<String, Object> map = new HashMap<>();
		map.put("myList", List.of("string1", "string2"));

		ObjectWriter writer = createXmlMapper(true).writer().withRootName("daRoot");

		String xmlFromModel = writer.writeValueAsString(pojo);
		String xmlFromMap = writer.writeValueAsString(map);

		System.out.println("xmlFromModel: " + xmlFromModel);
		System.out.println("xmlFromMap: " + xmlFromMap);

		assertThat("xml should match", xmlFromMap, equalTo(xmlFromModel));
	}

Reading such xml to a POJO works as expected:

	@Test
	public void xmDeserializationToPojoShouldReadCompleteList() throws IOException {
		SomePojo pojo = createXmlMapper(true).readValue(XML_WITH_WRAPPER, SomePojo.class);
		System.out.println(pojo);
		assertThat("all strings read with wrapper", pojo.myList, equalTo(List.of("string1", "string2")));

		pojo = createXmlMapper(false).readValue(XML_NO_WRAPPER, SomePojo.class);
		System.out.println(pojo);
		assertThat("all strings read no wrapper", pojo.myList, equalTo(List.of("string1", "string2")));
	}

But reading it to a Map<String,Object> fails. Reading XML_WITH_WRAPPER produces "{myList={myList=[string1, string2]}}", reading XML_NO_WRAPPER leads to "{myList=string2}", omitting "string1" altogether. In both cases I would expect the result to be "myList=[string1, string2]" to be consistent with POJOs:

	@Test
	public void xmlDeserializationToMapShouldReadCompleteList() throws IOException {
		XmlMapper om1 = createXmlMapper(true);
		JavaType type1 = om1.getTypeFactory().constructMapType(LinkedHashMap.class, String.class, Object.class);

		Map<String, Object> map = om1.readValue(XML_WITH_WRAPPER, type1);
		System.out.println(map);
		assertThat("all strings read with wrapper", map.get("myList"), equalTo(List.of("string1", "string2")));

		XmlMapper om2 = createXmlMapper(false);
		JavaType type2 = om1.getTypeFactory().constructMapType(LinkedHashMap.class, String.class, Object.class);

		map = om2.readValue(XML_NO_WRAPPER, type2);
		System.out.println(map);
		assertThat("all strings read no wrapper", map.get("myList"), equalTo(List.of("string1", "string2")));
	}

It would be great if you could have a look at this.

[cowtowncoder]

I hope to look at this later on, but one quick note I'll add.... there is one limitation to keep in mind is that in general, combinations of Maps/Lists of Maps/Lists do NOT work without intermediate POJO. This is limitation due to XML itself having no structures to distinguish array notion; there are only elements with attributes and content. As such Java object structure must be available to infer that an element should map into List (or, for unwrapped case, List element).

[cowtowncoder]

Another note: Map values do not have any wrapper/no-wrapper mechanism, so this is simply not supported.

At this point this is not expected to work the way indicated above: Maps are not POJOs, and while this distinction affects JSON handling to some degree too (anything called "properties" only applies to POJOs), it is even more so with XML.

I'll see if there is a way to indicate this better on README.

Thank's a lot for looking into this so quickly!

Unfortunately I don't know much about the inner workings of the library, so my suggestions might be a bit naive, but still:

Creating XML: wouldn't it be straightfoward to produce the wrapper element in addition to the elements (as already working), whenever there is an array or collection in the map and UseWrapper is true?

Reading XML: how I came accross this is that I have to read data (that I can't control) that sometimes looks like the XML_NO_WRAPPER data above. With the current code, reading this into a map, entries are silently skipped/overwritten. Would it be much effort to either raise an error if this occurs or even better to accumulate all such entries in a List when reading the second element into a map? If it's not part of the core library code, could I add such behaviour by using an extension mechanism offered by Jackson?

[cowtowncoder]

I guess it is not unreasonable to request for wrapping either to be applied for Maps too, or have another annotation for doing that. Historically this has not been done partly since JAXB does not really have any direct support for Maps (need converters I think), and although Jackson is not JAXB implementation, there is support for JAXB annotations and that guided design somewhat.

On Map handling wrt reading: it might make sense to have stricter checks; if you can isolate reading case a bit and file a separate issue that'd make sense?

So it'd be possible to file 2 separate issues. Of these, second, reporting error for Map reads, would probably be easier to implement.