GeoEvent Processor - javax.xml.ws.soap.SOAPFaultException: Unmarshalling Error

JacobHays · ‎09-25-2014

I'm running into an error with a GeoEvent Inbound Transport that I'm developing. The transport is acting as a web services client for a .Net web service that returns .Net datasets (which is unfortunate). I've done a simple proof of concept application outside of the GeoEvent Processor engine, which works fine for getting results from the web service, but when the code is run in the GeoEvent Processor I get the error shown below.

The associated WSDL (DataRetrieval_Sanitized.xml) and code snippet (CodeSnippet.txt) are attached. I'm using WSImport to generate the classes from the WSDL, with a workaround to get past problems with the .Net dataset (https://weblogs.java.net/blog/vivekp/archive/2007/05/how_to_deal_wit_1.html). I think the problem might be with how that workaround did some of the binding and how that binding is being interpreted when run in the GeoEvent Processor engine.

Ultimately I'm trying to figure out why the error occurs in the GeoEvent Processor engine while my proof of concept works, and what can I do to resolve this issue. I've posted this on stackoverflow with additional details to see if anyone has ideas on more general terms.

java - ArcGIS GeoEvent Processor - javax.xml.ws.soap.SOAPFaultException: Unmarshalling Error - Stack...

Note: I've altered the domain of the web service as shown in the error/wsdl/code to protect the (possibly) innocent.

Error:

at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:156)[120:org.apache.cxf.cxf-rt-frontend-jaxws:2.6.1]

at com.sun.proxy.$Proxy198.getCompanyArcgisData(Unknown Source)[367:com.somecompany.arcgis.geoevent.transport.inbound.somecompanyInboundTransport:1.0.0]

at com.somecompany.arcgis.geoevent.transport.inbound.SomeInboundTransport.callWebService(SomeInboundTransport.java:184)[367:com.somecompany.arcgis.geoevent.transport.inbound.somecompanyInboundTransport:1.0.0]

at com.somecompany.arcgis.geoevent.transport.inbound.SomeInboundTransport.run(SomeInboundTransport.java:257)[367:com.somecompany.arcgis.geoevent.transport.inbound.somecompanyInboundTransport:1.0.0]

at java.lang.Thread.run(Thread.java:722)[:1.7.0_17]

Caused by: javax.xml.bind.UnmarshalException

- with linked exception:

at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.handleStreamException(UnmarshallerImpl.java:425)

at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:362)

at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:339)

at org.apache.cxf.jaxb.JAXBEncoderDecoder.doUnmarshal(JAXBEncoderDecoder.java:784)[91:org.apache.cxf.cxf-rt-databinding-jaxb:2.6.1]

at org.apache.cxf.jaxb.JAXBEncoderDecoder.access$100(JAXBEncoderDecoder.java:97)[91:org.apache.cxf.cxf-rt-databinding-jaxb:2.6.1]

at org.apache.cxf.jaxb.JAXBEncoderDecoder$1.run(JAXBEncoderDecoder.java:812)

at java.security.AccessController.doPrivileged(Native Method)[:1.7.0_17]

at org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:810)[91:org.apache.cxf.cxf-rt-databinding-jaxb:2.6.1]

at org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:644)[91:org.apache.cxf.cxf-rt-databinding-jaxb:2.6.1]

at org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:157)[91:org.apache.cxf.cxf-rt-databinding-jaxb:2.6.1]

at org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:108)[87:org.apache.cxf.cxf-api:2.6.1]

at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:262)[87:org.apache.cxf.cxf-api:2.6.1]

at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:798)[87:org.apache.cxf.cxf-api:2.6.1]

at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1667)[118:org.apache.cxf.cxf-rt-transports-http:2.6.1]

at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1520)[118:org.apache.cxf.cxf-rt-transports-http:2.6.1]

at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1428)[118:org.apache.cxf.cxf-rt-transports-http:2.6.1]

at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)[87:org.apache.cxf.cxf-api:2.6.1]

at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:658)[118:org.apache.cxf.cxf-rt-transports-http:2.6.1]

at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)[87:org.apache.cxf.cxf-api:2.6.1]

at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:262)[87:org.apache.cxf.cxf-api:2.6.1]

at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:532)[87:org.apache.cxf.cxf-api:2.6.1]

at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:464)[87:org.apache.cxf.cxf-api:2.6.1]

at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:367)[87:org.apache.cxf.cxf-api:2.6.1]

at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:320)[87:org.apache.cxf.cxf-api:2.6.1]

at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:89)[119:org.apache.cxf.cxf-rt-frontend-simple:2.6.1]

at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:134)[120:org.apache.cxf.cxf-rt-frontend-jaxws:2.6.1]

... 4 more

at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.handleEvent(UnmarshallingContext.java:642)

at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:254)

at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:249)

at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportUnexpectedChildElement(Loader.java:116)

at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.childElement(Loader.java:101)

at com.sun.xml.bind.v2.runtime.unmarshaller.StructureLoader.childElement(StructureLoader.java:243)

at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement(UnmarshallingContext.java:478)

at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement(UnmarshallingContext.java:459)

at com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.handleStartElement(StAXStreamConnector.java:242)

at com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.bridge(StAXStreamConnector.java:176)

at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:360)

... 28 more

... 39 more

JacobHays · ‎10-22-2014

This is probably not the best answer on this, but it's what I came up with in case anyone runs into a similar problem.

The ArcGIS GeoEvent Processor that wrapped my OSGI project appeared to be doing some additional binding/unbinding of the web service that I referenced in my application. The work-around that I employed to get that .Net (DataSet return values) web service to function in Java just wasn't acceptable to the GeoEvent Processor.

My Solution

Ultimately what I did was create a secondary .Net web service which took the DataSet values and converted them to JSON, and returned JSON strings. This removed the problems encountered when attempting to reference DataSet return values from the web service, now I was dealing with a simple JSON string. The wsimport of that JSON web service went smooth, no work-around required. I tucked the newly imported web service files into my java project and now have no problems.

For Reference on C# DataSet to JSON:

Using Newtonsoft.Json (http://james.newtonking.com/json). After playing with a few other libraries for JSON serialization that is what I found worked best for me.
Newtonsoft.Json is available via NuGet package
Rick Strahl's site was a big help http://weblog.west-wind.com/posts/2008/Sep/03/DataTable-JSON-Serialization-in-JSONNET-and-JavaScript...

View solution in original post

JacobHays · ‎10-22-2014

This is probably not the best answer on this, but it's what I came up with in case anyone runs into a similar problem.

The ArcGIS GeoEvent Processor that wrapped my OSGI project appeared to be doing some additional binding/unbinding of the web service that I referenced in my application. The work-around that I employed to get that .Net (DataSet return values) web service to function in Java just wasn't acceptable to the GeoEvent Processor.

My Solution

Ultimately what I did was create a secondary .Net web service which took the DataSet values and converted them to JSON, and returned JSON strings. This removed the problems encountered when attempting to reference DataSet return values from the web service, now I was dealing with a simple JSON string. The wsimport of that JSON web service went smooth, no work-around required. I tucked the newly imported web service files into my java project and now have no problems.

For Reference on C# DataSet to JSON:

Using Newtonsoft.Json (http://james.newtonking.com/json). After playing with a few other libraries for JSON serialization that is what I found worked best for me.
Newtonsoft.Json is available via NuGet package
Rick Strahl's site was a big help http://weblog.west-wind.com/posts/2008/Sep/03/DataTable-JSON-Serialization-in-JSONNET-and-JavaScript...

JavierDelgadillo · ‎10-27-2014

Jacob,

Out of curiosity, what version of CXF did your POC use?

I'm also wondering if the issue was something to do with OSGi (the container which runs GeoEvent) and class loaders not being able to find your stub classes.

-Javier

JacobHays · ‎11-13-2014

I was using WSimport (Jax-WS RI) version 2.2.4-b01 to build the stubs for both the POC and my GeoEvent Transport. From the generated stubs:

/**

* This class was generated by the JAX-WS RI.

* JAX-WS RI 2.2.4-b01

* Generated source version: 2.2

*

*/

So perhaps you are on to something there, since the errors all seem to indicate a problem unmarshalling with CXF. Perhaps it is just an incompatibility between WSimport generated code and supporting that in CXF. I assume that CXF is being used by OSGi, since I don't import or reference CXF in my code as far as I can tell.

Since my POC did not utilize CXF, it probably avoided the issue. In hind sight perhaps I should have tried stub generation with CXF, I might still revisit that if I get some spare time.