XMLStreamException calling REST deployments/{depID}/resources

[joeysr20det]

I'm making a REST call to get the resources of a deployment in the repository. I have success calling:

http://mouse:8084/activiti-rest/service/repository/deployments/1506

to get the deployment info, but when I call:

http://mouse:8084/activiti-rest/service/repository/deployments/1506/resources

I get a HTTP 500 with the error message:

"An exception occured writing the response entity"

and this big long nasty stack trace in my Tomcat log:


Aug 07, 2014 4:46:00 PM org.restlet.engine.log.LogFilter afterHandle
INFO: 2014-08-07   16:46:00   2001:0:9d38:6ab8:10db:3a91:f5ff:ff43   kermit   2001:0:9d38:6ab8:10db:3a91:f5ff:ff43   8084   GET   /activiti-rest/service/repository/deployments/1506/resources   -   200   -   0   63   http://mouse:8084   Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0   -
Aug 07, 2014 4:46:00 PM org.restlet.engine.adapter.ServerAdapter commit
SEVERE: An exception occured writing the response entity
java.io.IOException: javax.xml.stream.XMLStreamException: Trying to output second root, <ArrayList>
   at com.fasterxml.jackson.dataformat.xml.util.StaxUtil.throwXmlAsIOException(StaxUtil.java:24)
   at com.fasterxml.jackson.dataformat.xml.ser.ToXmlGenerator._handleStartObject(ToXmlGenerator.java:428)
   at com.fasterxml.jackson.dataformat.xml.ser.ToXmlGenerator.writeStartObject(ToXmlGenerator.java:397)
   at com.fasterxml.jackson.databind.ser.BeanSerializer.serialize(BeanSerializer.java:138)
   at com.fasterxml.jackson.databind.ser.impl.IndexedListSerializer.serializeContents(IndexedListSerializer.java:100)
   at com.fasterxml.jackson.databind.ser.impl.IndexedListSerializer.serializeContents(IndexedListSerializer.java:21)
   at com.fasterxml.jackson.databind.ser.std.AsArraySerializerBase.serialize(AsArraySerializerBase.java:186)
   at com.fasterxml.jackson.databind.ser.DefaultSerializerProvider.serializeValue(DefaultSerializerProvider.java:222)
   at com.fasterxml.jackson.dataformat.xml.ser.XmlSerializerProvider.serializeValue(XmlSerializerProvider.java:87)
   at com.fasterxml.jackson.databind.ObjectWriter._configAndWriteValue(ObjectWriter.java:683)
   at com.fasterxml.jackson.databind.ObjectWriter.writeValue(ObjectWriter.java:534)
   at org.restlet.ext.jackson.JacksonRepresentation.write(JacksonRepresentation.java:474)
   at org.restlet.engine.adapter.ServerCall.writeResponseBody(ServerCall.java:519)
   at org.restlet.engine.adapter.ServerCall.sendResponse(ServerCall.java:463)
   at org.restlet.ext.servlet.internal.ServletCall.sendResponse(ServletCall.java:430)
   at org.restlet.engine.adapter.ServerAdapter.commit(ServerAdapter.java:196)
   at org.restlet.engine.adapter.HttpServerHelper.handle(HttpServerHelper.java:153)
   at org.restlet.ext.servlet.ServerServlet.service(ServerServlet.java:1118)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
   at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
   at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
   at org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter(MonitorFilter.java:393)
   at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
   at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
   at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:225)
   at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
   at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
   at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
   at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
   at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
   at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
   at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
   at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:999)
   at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:565)
   at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:309)
   at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
   at java.lang.Thread.run(Thread.java:745)
Caused by: javax.xml.stream.XMLStreamException: Trying to output second root, <ArrayList>
   at com.ctc.wstx.sw.BaseStreamWriter.throwOutputError(BaseStreamWriter.java:1522)
   at com.ctc.wstx.sw.BaseStreamWriter.throwOutputError(BaseStreamWriter.java:1529)
   at com.ctc.wstx.sw.BaseStreamWriter.reportNwfStructure(BaseStreamWriter.java:1557)
   at com.ctc.wstx.sw.BaseNsStreamWriter.checkStartElement(BaseNsStreamWriter.java:469)
   at com.ctc.wstx.sw.RepairingNsStreamWriter.writeStartOrEmpty(RepairingNsStreamWriter.java:255)
   at com.ctc.wstx.sw.BaseNsStreamWriter.writeStartElement(BaseNsStreamWriter.java:310)
   at com.fasterxml.jackson.dataformat.xml.ser.ToXmlGenerator._handleStartObject(ToXmlGenerator.java:426)
   … 36 more




Anyone seen anything like this? Also I'm stilling getting XML on some of my REST responses from Activiti while others are JSON as they should be. Are there some issues with the Activiti 5.16 REST stack? I want to make sure our workflow editor will work with 5.16, but I'm getting ready to rollback to 5.15 and just certify it for instead. 5.16 just isn't working well for me.

[jbarrez]

5.16 didn't have much changes in the rest API. But you say the very same call is working on 5.15?

[joeysr20det]

Yes that's right. I don't know whats changed. I'm pretty familiar with your source code and design and couldn't find any noticeable changes from 5.15 to 5.16 with respect to REST.

However, the Accept: application/json HTTP header solves this issue for sure. I've done a great deal of searching and it's highly recommended to specify the Accept header to identify the HTTP response format you expect to receive as the client. I read from a lot of JSON people that there are so many subtle differences at the transport layer from platform to plaform, version to version, etc…. that they just always make sure to use the header. It might be a good idea to throw this in the beginning of the REST section of the user manual.

Keep up the good work. The Activiti is doing a great job. I've worked with many workflow engines and like yours the best by far.

[jbarrez]

That is indeed odd that suddenly these headers are needed.
I added it to the userguide: https://github.com/Activiti/Activiti/commit/abdc39bf386588e71579b9b933c0fd82798a1047

Thanks. And thanks for the positive feedback 🙂