WSDL-Axis2 CodeGen Problem

Question

Hello, I am having a problem sending a WS Request to a Server. It seems that the Namespace(NS) in one of the ComplexTypes of an operation types is causing an xsi:type to be spewed as part of the generated SOAP Request.

Please see below for WSDL Sample:

<xs:complexType name="SubscribeAppendantProductRequest">
<xs:complexContent>
<xs:extension base="business:Common">
<xs:sequence>
<xs:element maxOccurs="unbounded" name="Product">
<xs:complexType>
<xs:complexContent>
<xs:extension base="business:Product">
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="0" name="Service" type="business:Service" />
<xs:element minOccurs="0" name="EffectiveDate" type="xs:string" />
<xs:element minOccurs="0" name="ExpireDate" type="xs:string" />
<xs:element name="ValidMode" type="business:ValidMode" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element minOccurs="0" name="HandlingChargeFlag" type="xs:int" />
<xs:element minOccurs="0" name="CustID" type="xs:string" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>

See below for the the code generating the request on the Axis2 Operation/Stub:

SubscribeAppendantProductRequest sub_req = new SubscribeAppendantProductRequest();
Product_type2 subscribedToProduct = new Product_type2();
subscribedToProduct.setId(productKey);
subscribedToProduct.setValidMode(ValidMode.value1);
Product_type2 []subscribedProductList = new Product_type2[1];
subscribedProductList[0]=subscribedToProduct;
sub_req.addProduct(subscribedToProduct);
sub_req.setProduct(subscribedProductList);
sub_req.setSubscriberNo(subscriber);
return sub_req;

Everytime I send a request, i get the following error message :

Interface parameter fault:There has 1 XML Validation Errors: Invalid xsi:type qname: 'ns2:Product_type2' in element SubscribeAppendantProductRequest

See below for generated SOAP Request:

<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"&gt;
<soapenv:Body>
<ns3:SubscribeAppendantProductRequestMsg xmlns:ns3="http://www.huawei.com/bme/cbsinterface/cbs/businessmgrmsg"&gt;
<RequestHeader>
<ns1:CommandId xmlns:ns1="http://www.huawei.com/bme/cbsinterface/common"&gt;SubscribeAppendantProduct&lt;/ns1:CommandId&gt;
<ns1:Version xmlns:ns1="http://www.huawei.com/bme/cbsinterface/common"&gt;1.0&lt;/ns1:Version&gt;
<ns1:TransactionId xmlns:ns1="http://www.huawei.com/bme/cbsinterface/common"&gt;trans001&lt;/ns1:TransactionId&gt;
<ns1:SequenceId xmlns:ns1="http://www.huawei.com/bme/cbsinterface/common"&gt;2002396871686&lt;/ns1:SequenceId&gt;
<ns1:RequestType xmlns:ns1="http://www.huawei.com/bme/cbsinterface/common"&gt;Event&lt;/ns1:RequestType&gt;
<ns1:SerialNo xmlns:ns1="http://www.huawei.com/bme/cbsinterface/common"&gt;2002396871686&lt;/ns1:SerialNo&gt;
</RequestHeader>
<SubscribeAppendantProductRequest xmlns:ns2="http://www.huawei.com/bme/cbsinterface/cbs/businessmgr" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ns2:SubscribeAppendantProductRequest">
<ns2:SubscriberNo>8090547759</ns2:SubscriberNo>
<ns2:Product xsi:type="ns2:Product_type2">
<ns2:Id>121390</ns2:Id>
<ns2:ValidMode>4050000</ns2:ValidMode>
</ns2:Product>
</SubscribeAppendantProductRequest>
</ns3:SubscribeAppendantProductRequestMsg>
</soapenv:Body>
</soapenv:Envelope>

I believe the problem is with the base extension of the Product complex type.

Funnily enough, I had run a similar program on a different operation type with similar characteristics which worked OK. See below for WSDL Sample of Functional Operation:

<xs:complexType name="UnSubscribeAppendantProductRequest">
<xs:complexContent>
<xs:extension base="business:Common">
<xs:sequence>
<xs:element maxOccurs="unbounded" name="Product">
<xs:complexType>
<xs:sequence>
<xs:element name="ProductID" type="xs:string" />
<xs:element minOccurs="0" name="ProductOrderKey" type="xs:string" />
<xs:element name="ValidMode" type="xs:string" />
<xs:element minOccurs="0" name="ExpireDate" type="xs:string" />
<xs:element maxOccurs="unbounded" minOccurs="0" name="Service">
<xs:complexType>
<xs:sequence>
<xs:element name="Id" type="xs:string" />
<xs:element maxOccurs="unbounded" name="SimpleProperty" type="business:SimpleProperty" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element minOccurs="0" name="CustID" type="xs:string" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>

When I did a compare , it seems that they both use the Product complex Type but it seems that the faulty uses Product complex type as an extension.

Does anyone have experience with this? Any possible solutions? Would things be different if I used a different Data Binding ( from ADB that is)?

Answer 1

I eventually decided to use the 'xmlbeans' data binding format for the Outputted Generated Java classes representing the WSDL operations.

It seems that the Axis2 data binding (ADB) does not handle WSDL with multiple Complex Types ( which are, when translated to Java code, return Java Objects) especially if they are configured with XMLSchema attributes maxOccurs='unbounded' .

When the output is generated when using ADB it seems that a separate Object_x ( where x is an integer ranging from 1..n) is created for every Complex Type called Object which would require different properties depending on the Operation requirements as defined in the WSDL document. The Object_x would be placed in the same package as the other objects generated by wsdl2java. The sent SOAP request then contains a type=Object_x XSD Attribute accompanying the translation of the Object to the SOAP request as shown in the initial question.

When the output is generated when using xmlbeans, a package.Object class is generated by wsdl2java where the package is the name of the Operation while the Object is the Complex type and it seems that xmlbeans disregards the maxOccurs='unbounded' attribute and the sent SOAP request does not have any type paramters placed in it.

Well this was how I solved this problem. I have sent in a bug report to the Axis2 development team but I will keep following it up to see if there are any resolutions in future versions.

Thanks to all who tried.