Improve CastorMarshaller support for loading class descriptors [SPR-6003]

[spring-projects-issues]

Stevo Slavić opened SPR-6003 and commented

Spring framework's CastorMarshaller currently supports specifying class descriptors only via mapping XML files or by defining a single class. Please extend support for specifying multiple classes via packages (string array) and possibly via classes (class array) too.

OXM is regularly used in context of developing web services. With contract first approach, and Castor's (directly or via castor-maven-plugin) support for generating DTO classes and their descriptor classes from XSD's, using mapping xml files is no longer needed. In fact it is advised to use descriptor classes instead of mapping XML because of value added through better support for validation, etc. It would be good if Spring OXM would come bundled with this workflow supported.

See following related castor mailing list discussion for more details: http://www.mail-archive.com/user@castor.codehaus.org/msg07593.html

---

Affects: 2.5.6, 3.0 M3

Attachments:

• org.springframework.oxm-EnhancedCastorSupport.patch (26.74 kB)

Referenced from: commits 157a87e

1 votes, 3 watchers

[spring-projects-issues]

Werner Guttmann commented

Let me just add to this a bit:

a) With Castor XML, one is able to generate domain classes (plus descriptor classes plus .castor.cdr) files from a given set of XML schemas.
b) Once you have done so, and you have included all of the classes/files mentioned above on your class path, ...
c) One can create an instance of XMLContext, and instantiate a Castor (Un)Marshaller instance as follows

XMLContext context = new XMLContext();
Unmarshaller unmarshaller = context.createUnmarshaller();

By definition, as long as requirement b) is met, you will be able to unmarshal to any of the domain classes as generated in step a) issuing

SomeClass someClass = (SomeClass) unmarshaller.unmarshal(...);

I don't see a reason why this should not be supported.

[spring-projects-issues]

Stevo Slavić commented

Wish Spring-OXM dependency to Castor 1.2 (org.codehause.castor:castor) would be upgraded to Castor 1.3 (org.codehaus.castor:castor-xml) as well, but I guess that's not likely since this Castor issue hasn't been resolved yet, unless SpringSource creates and adds Castor 1.3 bundle to SpringSource EBR.

[spring-projects-issues]

Stevo Slavić commented

Attaching "org.springframework.oxm-EnhancedCastorSupport.patch" created against Spring-OXM v3.0.0.BUILD-SNAPSHOT (r1733).

This patch enhances support for configuring multiple Castor descriptor classes to CastorMarshaller using:

-Class array (replaces previous single Class option; users just need to rename property name in their Spring context's, from targetClass to targetClasses)
-package names array (newly added; package names should be specified as CSV strings in Spring context configuration)

Previously one could either specify single class or mapping file(s). Proposed solution allows configuring CastorMarshaller using all 3 means together or in any combination.

Existing tests have been adjusted. Patch doesn't contain additional test case for new package names array configuration option.

[spring-projects-issues]

Arjen Poutsma commented

Deferring until we Castor 1.3 is added to the EBR.

[spring-projects-issues]

Werner Guttmann commented

Arjen, there's absolutely no requirement to depend on castor 1.3 for this. As mentioned above, it would be a nice to have.

[spring-projects-issues]

Arjen Poutsma commented

Oops, guess I misunderstood. I've put in a request to put in 1.3 in the EBR anyway.

Rerescheduling for 3.0 again :).

[spring-projects-issues]

Werner Guttmann commented

Thanks, Arjen. Just one more thing: please note that Stevo's patch addresses some of the issues mentioned. It definitely does not the address the fact that when you start with source generation using castor XML, one does not need to register any classes with Castor XML for (un)marshalling to get things working.

[spring-projects-issues]

Arjen Poutsma commented

I think it actually does address that issue. If no mapping location, target classes or packages are defined, a default empty XMLContext is created. Or am I missing something again?

Stevo, can you comment on this?

[spring-projects-issues]

Stevo Slavić commented

Yes, with addition: if one wants control over which of multiple classes, or packages should be registered with a given Castor's XMLContext , there was only mapping.xml option; while with the patch one can explicitly specify classes/packages.

[spring-projects-issues]

Arjen Poutsma commented

Patch applied, thanks!

The only major change I made was to leave the targetClass property in place, for backwards compat reasons.