Implementing XMLNameTransformer breaks JSON mapping of abstract classes [message #1111836] |
Wed, 18 September 2013 20:09 |
Andy Chillrud Messages: 1 Registered: September 2013 |
Junior Member |
|
|
I'm using Jersey 2.2 with EclipseLink 2.5.0 to implement a REST API on top of a third party SDK. I have implemented my own representation wrapper around one of the 3rd party classes, and am using JAXB annotations in my wrapper class to generate JSON and XML.
I have implemented GET and POST operations which produce and consume either JSON or XML. This is working correctly, however the JSON fieldnames/XML element names for the wrapped 3rd party class are camel case (fieldId) and I have a requirement that they be snake case (field_id).
I created a XMLNameTransformerXML implementation that transforms element names, and implemented a XML mapping file for the 3rd party package, which is loaded by an implementation of ContextResolver<JAXBContext>. All the XML mapping file really does is reference my XMLNameTransformerXML implementation.
This seemed to work, and the field/elements names generated for the 3rd party class when I perform a GET are now displayed in snake case. However the POST operation is only successful with XML. When I pass it JSON I get an exception:
http-0.0.0.0-11090-1 2013-09-18 14:58:17,031 | ERROR | session= | user= | org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/example].[Jersey Web Application] | Servlet.service() for servlet Jersey Web Application threw exception
Local Exception Stack:
Exception [EclipseLink-43] (Eclipse Persistence Services - 2.5.0.v20130507-3faac2b): org.eclipse.persistence.exceptions.DescriptorException
Exception Description: Missing class for indicator field value [example.jersey.representations.ConcreteExampleA] of type [class java.lang.String].
Descriptor: XMLDescriptor(example.jersey.representations.AbstractExample --> [])
The 3rd party class contains several members that are defined as Lists of abstract objects. This is where the problem seems to lie. Looking at the source code for the 3rd party library, each of the abstract base classes has a @XmlSeeAlso annotation that lists the concrete derived classes.
I implemented a test case that doesn't use the 3rd party (see attached zip file), and am able to reproduce the problem.
Any suggestions?
Thanks, Andy
|
|
|
|
Powered by
FUDForum. Page generated in 0.04353 seconds