An implementation of AbstractJaxb2HttpMessageConverter that can work with EclipseLink MOXy external binding definitions [SPR-9758]

[spring-projects-issues]

Michał Politowski opened SPR-9758 and commented

EclipseLink MOXy supports defining the bindings in an external definitions file instead of using annotations. The currently available Jaxb2RootElementHttpMessageConverter cannot be used when this feature is used, for two reasons:

1. the JAXB context is created by the converter using the JAXBContext.newInstance(Class...) method. To use the external definition files with MOXy a context property must be specified using the newInstance variant taking a map;
2. the converter decides if it can read/write an object by looking for an @XmlRootElement annotation, which will be absent for bindings defined completely externally.

A variant of the converter that eg. lets the user provide ready JAXB contexts for certain classes and assumes these classes are thus supported no matter what the annotations say could solve both problems.

---

Affects: 3.1 GA

Issue Links:

• Allow Jaxb2Marshaller to work with EclipseLink MOXy when using external binding definitions [SPR-9757] #14391 Allow Jaxb2Marshaller to work with EclipseLink MOXy when using external binding definitions

[spring-projects-issues]

Arjen Poutsma commented

Note that when #14391 is fixed, there is no need for a separate MOXy HttpMessageConverter, as you could simply use the MarshallingHttpMessageConverter with the standard Jaxb2Marshaller.

[spring-projects-issues]

Rossen Stoyanchev commented

Michał, this should address the issue. Please confirm or elaborate otherwise.

[spring-projects-issues]

Michał Politowski commented

Yes, I think this should solve my MOXy use case.

Note that I did not really suggest a separate MOXy specific HttpMessageConverter. And there are probably other situations where a converter (or Marshaller?) configured with a preexisting JAXB context would make sense.
Eg. just because the developer already has to have one anyway for some other use. Which actually it seems we do, because of a need for a stateful unmarshaller listener. But we can live with having two JAXB contexts created, one by hand, one by Jaxb2Marshaller.