Bug? SOAP response causes ArrayIndexOutOfBoundsEx

[tomstrummer]

I am trying to consume a 3rd party web service. When JBossWS parses the response, an ArrayIndexOutOfBoundsException is thrown from the JBoss XML binding code. I have generated stubs using the wstools command.

I'm guessing this is a bug? I would love to help debug it but I'm kinda lost.. I'm not sure what namespace-to-package name conversion should be going on when the SOAP response is parsed since the mapping is already done in a jaxrpc-mapping.xml file. And the jaxrpc-mapping isn't parsed each time a response is sent, right?

WS Response:

<?xml version="1.0"?>
<SOAP-ENV:Envelope
 xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">
 <SOAP-ENV:Body SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
 xmlns:NS2="Gridlogix.EnNET.Types">
 <NS1:GetObjectResponse xmlns:NS1="Gridlogix.EnNET.Types.IEnNET">
 <return xsi:type="NS2:GlxObject">
 <Identifier xsi:type="NS2:GlxIdentifier">
 <Name xsi:type="xsd:string">Servers</Name>
 <DisplayName xsi:type="xsd:string"></DisplayName>
 <Index xsi:type="xsd:int">0</Index>
 <Scope xsi:type="NS2:GlxMemberScope">msPublic</Scope>
 <ClassID xsi:type="xsd:string">BACServerList</ClassID>
 <TypeID xsi:type="xsd:int">1464013352</TypeID>
 </Identifier>
 <ObjectCount xsi:type="xsd:int">5</ObjectCount>
 <PropertyCount xsi:type="xsd:int">4</PropertyCount>
 <MethodCount xsi:type="xsd:int">7</MethodCount>
 <DefaultProperty xsi:type="xsd:string"></DefaultProperty>
 <Interfaces xsi:type="xsd:string">
 IBACServerList,IPersistable
 </Interfaces>
 <ListClass xsi:type="xsd:string">GlxServer</ListClass>
 </return>
 </NS1:GetObjectResponse>
 </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

jaxrpc-mapping looks like this:

<?xml version='1.0' encoding='UTF-8'?><java-wsdl-mapping version='1.1' xmlns='http://java.sun.com/xml/ns/j2ee' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xsi:schemaLocation='http://java.sun.com/xml/ns/j2ee http://www.ibm.com/webservices/xsd/j2ee_jaxrpc_mapping_1_1.xsd'>
 <package-mapping>
 <package-type>com.gridlogix.webservices</package-type>
 <namespaceURI>Gridlogix.EnNET.Types</namespaceURI>
 </package-mapping>
 <package-mapping>
 <package-type>com.gridlogix.webservices</package-type>
 <namespaceURI>http://www.gridlogix.com/WebServices/</namespaceURI>
 </package-mapping>
 <java-xml-type-mapping>
 <java-type>com.gridlogix.webservices.GlxVersionInfo</java-type>
 <root-type-qname xmlns:typeNS='Gridlogix.EnNET.Types'>typeNS:GlxVersionInfo</root-type-qname>
 <qname-scope>complexType</qname-scope>
 <variable-mapping>
 ....

And the WSDL looks like this:

<?xml version="1.0" encoding="utf-8"?>
<definitions xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:xs="http://www.w3.org/2001/XMLSchema" name="IEnNETService"
targetNamespace="http://www.gridlogix.com/WebServices/"
xmlns:tns="http://www.gridlogix.com/WebServices/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
xmlns:ns1="Gridlogix.EnNET.Types">
 <types>
 <xs:schema targetNamespace="Gridlogix.EnNET.Types" xmlns="Gridlogix.EnNET.Types">
 <xs:complexType name="GlxRem">
 <xs:sequence/>
 </xs:complexType>
 .....

Finally.. the stack trace...

java.rmi.RemoteException: Call invocation failed; nested exception is:
 org.jboss.ws.WSException: org.jboss.ws.core.binding.BindingException: org.jboss.ws.core.jaxrpc.binding.jbossxb.UnmarshalException: Failed to parse source: 21
 at org.jboss.ws.core.jaxrpc.client.CallImpl.invokeInternal(CallImpl.java:536)
 at org.jboss.ws.core.jaxrpc.client.CallImpl.invoke(CallImpl.java:277)
 at org.jboss.ws.core.jaxrpc.client.PortProxy.invoke(PortProxy.java:151)
 at $Proxy277.getObject(Unknown Source)
 at com.enernoc.eea.dpm.web.TestServiceServlet.doGet(TestServiceServlet.java:57)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
 at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
 at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
 at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
 at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
 at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
 at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
 at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
 at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
 at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
 at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
 at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
 at java.lang.Thread.run(Thread.java:619)
Caused by: org.jboss.ws.WSException: org.jboss.ws.core.binding.BindingException: org.jboss.ws.core.jaxrpc.binding.jbossxb.UnmarshalException: Failed to parse source: 21
 at org.jboss.ws.core.soap.XMLContent.unmarshallObjectContents(XMLContent.java:250)
 at org.jboss.ws.core.soap.XMLContent.transitionTo(XMLContent.java:97)
 at org.jboss.ws.core.soap.DOMContent.transitionTo(DOMContent.java:77)
 at org.jboss.ws.core.soap.SOAPContentElement.transitionTo(SOAPContentElement.java:140)
 at org.jboss.ws.core.soap.SOAPContentElement.getObjectValue(SOAPContentElement.java:171)
 at org.jboss.ws.core.EndpointInvocation.transformPayloadValue(EndpointInvocation.java:263)
 at org.jboss.ws.core.EndpointInvocation.getReturnValue(EndpointInvocation.java:197)
 at org.jboss.ws.core.CommonClient.syncOutputParams(CommonClient.java:499)
 at org.jboss.ws.core.CommonClient.invoke(CommonClient.java:387)
 at org.jboss.ws.core.jaxrpc.client.CallImpl.invokeInternal(CallImpl.java:517)
 ... 24 more
Caused by: org.jboss.ws.core.binding.BindingException: org.jboss.ws.core.jaxrpc.binding.jbossxb.UnmarshalException: Failed to parse source: 21
 at org.jboss.ws.core.jaxrpc.binding.JBossXBDeserializer.deserialize(JBossXBDeserializer.java:111)
 at org.jboss.ws.core.jaxrpc.binding.JBossXBDeserializer.deserialize(JBossXBDeserializer.java:62)
 at org.jboss.ws.core.binding.DeserializerSupport.deserialize(DeserializerSupport.java:60)
 at org.jboss.ws.core.soap.XMLContent.unmarshallObjectContents(XMLContent.java:180)
 ... 33 more
Caused by: org.jboss.ws.core.jaxrpc.binding.jbossxb.UnmarshalException: Failed to parse source: 21
 at org.jboss.ws.core.jaxrpc.binding.jbossxb.JBossXBUnmarshallerImpl.unmarshal(JBossXBUnmarshallerImpl.java:65)
 at org.jboss.ws.core.jaxrpc.binding.JBossXBDeserializer.deserialize(JBossXBDeserializer.java:103)
 ... 36 more
Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: 21
 at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:179)
 at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:126)
 at org.jboss.ws.core.jaxrpc.binding.jbossxb.JBossXBUnmarshallerImpl.unmarshal(JBossXBUnmarshallerImpl.java:61)
 ... 37 more
Caused by: java.lang.ArrayIndexOutOfBoundsException: 21
 at org.jboss.xb.binding.Util.xmlNamespaceToJavaPackage(Util.java:229)
 at org.jboss.xb.binding.Util.xmlNameToClassName(Util.java:310)
 at org.jboss.xb.binding.sunday.unmarshalling.impl.runtime.RtCharactersHandler.unmarshal(RtCharactersHandler.java:83)
 at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.endElement(SundayContentHandler.java:985)
 at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.endElement(SundayContentHandler.java:246)
 at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$DelegatingContentHandler.endElement(SaxJBossXBParser.java:296)
 at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
 at org.apache.xerces.xinclude.XIncludeHandler.endElement(Unknown Source)
 at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source)
 at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
 at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
 at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
 at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
 at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
 at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
 at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
 at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:175)
 ... 39 more

Thanks in advance...

[tomstrummer]

I hate to bump this but I was really hoping for some help since JBossWS seemed to be the only toolkit that was getting me anywhere with this old RPC/encoded service. Most of the other Java WS frameworks wouldn't even generate the client stub classes from the WSDL.

I'd be happy to give more details, file a bug report, dig into code, etc but I'm at a loss as to where to start. Is this even supported by JBossWS anymore? I know RPC/encoded services are not WS-I compliant and all that jazz, but that doesn't help me since I have an old 3rd party service that I have to integrate with :(

My last resort will be hand-crafting the request and response! And the WSDL is not trivial since there are a number of complex types. Any help would be greatly appreciated!

[ropalka]

"tomstrummer" wrote:

I'd be happy to give more details, file a bug report, dig into code, etc but I'm at a loss as to where to start. Is this even supported by JBossWS anymore? I know RPC/encoded services are not WS-I compliant and all that jazz, but that doesn't help me since I have an old 3rd party service that I have to integrate with :(

No, we don't support RPC/encoded as well :(

[tomstrummer]

But you (and Axis1) could actually generate client stubs! Damn. I think there is absolutely no Java WS framework that supports RPC/encoded services. I'm pretty sure I've tried them all. What's worse, the difference in the message seems almost trivial.

Maybe some XSL magic could help... Does JBossWS offer the ability to hook into the XML event stream before it's sent on to the XML-> Java mapping?

[tomstrummer]

Ok! I was actually able to convert the rpc/encoded WSDL to rpc/literal. So I use my modified WSDL against the service rather than their rpc/encoded one. I realized the response is valid rpc/literal, just with some added xsi:type attributes.

First step: convert the WSDL:
Convert the <soap:body attribute to use="literal" and remove the encodingStyle attribute.

Second step: convert any complexTypes to not extend soapenc:Array:
Any types that use <xs:restriction base="soapenc:Array"> can be changed to this:
For a loosely-typed array (JAXB will map it to a List):

<xs:complexType name="VariantArray">
 <xs:complexContent>
 <xs:extension base="ns1:GlxNode">
 <xs:sequence>
 <xs:any namespace="##any" minOccurs="0" maxOccurs="unbounded" processContents="lax" />
 </xs:sequence>
 </xs:extension>
 </xs:complexContent>
 </xs:complexType>

or for a typed List:

 <xs:complexType name="StringArray">
 <xs:complexContent>
 <xs:extension base="ns1:GlxNode">
 <xs:sequence>
 <xs:element name="String" type="xs:string" minOccurs="0" maxOccurs="unbounded" />
 </xs:sequence>
 </xs:extension>
 </xs:complexContent>
 </xs:complexType>

Just chose your own "base" type to extend or just create a new ComplexType.

Note also that I ended up switching to Metro (JAX-WS) 1.2 rather than JBossWS. But using JBossWS as a client seemed to work as well.

This is a bit of a pain but still a hell of a lot better than not being able to consume an RPC/encoded service or being stuck using Axis 1. Hope this helps someone as I couldn't find any other solution in all my searching.