OXM does not permit targetClass and mapping file for CastorMarshaller [SPR-5634]

[spring-projects-issues]

Darren Davison opened SPR-5634 and commented

org.springframework.oxm.castor.CastorMarshaller has an afterPropertiesSet() check that explicitly disallows a targetClass and a mappings location to be set on the same instance.

However, there is at least one use case where this is required: unmarshalling a collection (where the root element in the XML represents some collection instance). In this case, the targetClass specifies the required collection type, and the mappings are used as normal to instruct castor how to handle the other elements.

In the example here, the unmarshaller would return an ArrayList containing 2 items, where the item class is defined in the mapping location file.

<items>
  <item><name>Foo</name><price>100</price></item>
  <item><name>Bar</name><price>200</price></item>
</items

Mapping mapping = new Mapping();
mapping.loadMapping(..); // <-- mappingLocation
Unmarshaller u = new Unmarshaller();
u.setClass(ArrayList.class); // <-- targetClass
u.setMapping(mapping);

ArrayList ev2 = (ArrayList) u.unmarshal(new StringReader(xml));

See http://www.castor.org/how-to-map-a-list-at-root.html for a fuller description.

As a workaround, I tried extending CastorMarshaller, overriding customiseUnmarshaller(Unmarshaller) in order to set the target class on it, but this still fails. I'll try looking into deeper into this one.

---

Affects: 2.5.6

Referenced from: commits c166768

1 votes, 0 watchers

[spring-projects-issues]

Werner Guttmann commented

Being a Castor committer, I am able to confirm that this is a valid (and required) use case of Castor's Unmarhaller.

[spring-projects-issues]

Darren Davison commented

The issue with my overridden method was a config error on my part. This does actually work. So, if CastorMarshaller were to forego the check on not allowing targetClass and mapping to be set together, then I think this would work for unmarshalling a collection without having to extend the class. I haven't looked to see what the side effects of this might be for other uses of CastorMarshaller. At worst, I suspect it may lead to "unexpected behaviour" for the user.

Would be very helpful if this could be changed and backported to the current 1.5.x series of OXM.

Cheers,

[spring-projects-issues]

Arjen Poutsma commented

Fixed in Spring 3.0 svn