Axis2 fails when an XSD element has no type defined (type ur-type), but sub-types are returned in the SOAP response?

Question

I am facing an issue with a SOAP Web Service Client using Axis2; the XSD file extending the WSDL holds the following definition for an element in the response, notice how no type is defined:

<xs:element name="error" minOccurs="0"/>

Following is the actual response returned by the SOAP service:

<error>
   <details>Unexpected Error Occurred</details>
</error>

This is causing the following exception to be thrown by Axis2:

org.apache.axis2.AxisFault: javax.xml.stream.XMLStreamException: element text content may not contain START_ELEMENT
                at org.apache.axis2.AxisFault.makeFault(AxisFault.java:430)
                at fr.cel.service.HooStub.fromOM(HooStub.java:847

The Service people are saying that since the 'error' element has no type define, then it can include everything such as string, date or an additional structure.

I wasn't really convinced; so, what does it mean to have no type defined for the element ?

Also, is there any change we can apply to the WSDL or to the Axi2 wsdl2java stub generation command, so that we avoid this ? Knowing that instead of <details> we may actually receive some other sub-type in the response.

Update: I'm using Axis2 1.5.4, and it appears that W3C XSD specs say that we can have sub-types in this case (when using ur-type, i.e. no type defined), so why is Axis2 refusing this ?

Service people are right, have a look at stackoverflow.com/questions/7104455/… : any content should be allowed within the <error> element. See also XML Schema spec 3.3 Element declarations — potame
I agree now.. So can I remedy this in Axis2 ? Only option until now is to manually edit generated stub code.. yuck ! There's a pretty high cost if I have to move my project to Apache CXF. — abdelrahman-sinno

kjhughes kjhughes · Accepted Answer · 2015-11-04T12:43:47

Your service people are correct.

Per the W3C XSD Recommendation, 3.3.2 XML Representation of Element Declaration Schema Components:

{type definition} The type definition corresponding to the or element information item in the [children], if either is present, otherwise the type definition ·resolved· to by the ·actual value· of the type [attribute], otherwise the {type definition} of the element declaration ·resolved· to by the ·actual value· of the substitutionGroup [attribute], if present, otherwise the ·ur-type definition·.

Following the link for ur-type will yield that no type specified defaults to anyType.

You can certainly tighten the definition for error by providing a type that requires a detail element. Whether this avoids your exception is unclear as given only the constraints of the XSD, you should be able to put a details element within error. Your application software (Axis2) may be imposing additional requirements not specified purely by the XSD.

Axis2 fails when an XSD element has no type defined (type ur-type), but sub-types are returned in the SOAP response?

1 Answers