Forum Home » Fuse Distributions » Fuse Services Framework

Thread: Problem with JSONProvider & dropRootElement

This question is not answered. Helpful answers available: 2. Correct answers available: 1.

Permlink Replies: 0 Threads: [ Previous | Next ]

Posts: 13
Registered: 08/12/11
Problem with JSONProvider & dropRootElement
Posted: Oct 4, 2011 7:47 PM
  Click to reply to this thread Reply

I ran into a problem with a camel cxfrs endpoint that is caused by what appears to be a bug in JSONProvider/JSONUtils when configured with dropRootElement true.

Based on guidance in for the simplest way to deal with collections, I created a Topics class to represent a collection of topics. It has a getTopics method with return type Collection<Topic>. My web service @Produces("application/json") and has a method getTopics with return type Topics. With default JSONProvider settings, the web service method returns something like the following:


To get rid of the outer topics name, I configured the JSONProvider with dropRootElement = true. However that caused the following exception: Too many closing tags.
at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(
at com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(
at org.apache.cxf.jaxrs.provider.JSONProvider.marshal(
at org.apache.cxf.jaxrs.provider.JSONProvider.marshal(
at org.apache.cxf.jaxrs.provider.JSONProvider.writeTo(
at org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.serializeMessage(
at org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.processResponse(
at org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.handleMessage(
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(
at org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(
at org.apache.cxf.phase.PhaseInterceptorChain.resume(
at org.apache.cxf.transport.ChainInitiationObserver.onMessage(
at org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(
at org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(
at org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(
at org.eclipse.jetty.server.handler.ContextHandler.doScope(
at org.eclipse.jetty.server.handler.ScopedHandler.handle(
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(
at org.eclipse.jetty.server.Server.handleAsync(
at org.eclipse.jetty.server.HttpConnection.handleRequest(
at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(
at org.eclipse.jetty.http.HttpParser.parseNext(
at org.eclipse.jetty.http.HttpParser.parseAvailable(
at org.eclipse.jetty.server.HttpConnection.handle(
at org.eclipse.jetty.util.thread.QueuedThreadPool$
Caused by: Too many closing tags.
at org.codehaus.jettison.mapped.MappedXMLStreamWriter.writeEndElement(
at org.apache.cxf.staxutils.DelegatingXMLStreamWriter.writeEndElement(
at org.apache.cxf.jaxrs.provider.JSONUtils$IgnoreContentJettisonWriter.writeEndElement(
at com.sun.xml.bind.v2.runtime.output.XMLStreamWriterOutput.endTag(
at com.sun.xml.bind.v2.runtime.output.XmlOutputAbstractImpl.endTag(
at com.sun.xml.bind.v2.runtime.output.NamespaceContextImpl$Element.endElement(
at com.sun.xml.bind.v2.runtime.XMLSerializer.endElement(
at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(
at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsSoleContent(
at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeRoot(
at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(
at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(
... 30 more

The problem is occurring because the name of the class (Topics) matches the name of its property (getTopics) when translated to their json equivalents (topics). JSONProvider uses JSONUtils whose inner class IgnoreContentJettisonWriter uses the qualified name of the root element to know when to drop the json outer object wrapper that represents the class being serialized. When the class name matches the property name, the algorithm drops not only the outer object wrapper, but also drops the name of the matching property.

A workaround was to add a namespace to the Topics class's @XmlRootElement.

The workaround was easy, but it took me a day to figure out what was going on, and it seems like the dropRootElement solution should be more aware of whether it's really dropping the root element vs. a name/value pair with a name that matches the root name.

Can someone with more experience with this code check my conclusions? And if you agree that it's a problem, please let me know what I need to do to get the bug logged properly.