Subclassed POJO not correct in WSDL and webservice XML
------------------------------------------------------
Key: XFIRE-839
URL: http://jira.codehaus.org/browse/XFIRE-839
Project: XFire
Issue Type: Bug
Components: Aegis Module
Affects Versions: 1.2.4
Environment: IBM RAD 6 with WAS 5.1 Test Environment
Reporter: Joost den Boer
Assigned To: Dan Diephouse
I have several webservices. All methods return an IResult (=interface). Most
methods return a ResultImpl object (implements IResult).
The ResultImpl object contains a Hashtable property 'result'. For ResultImpl,
the Aegis binding defines this property to be of type <String>,<Object>.
ResultImpl binding:
<mappings xmlns:ail="http://www.aegon.com/ail/spil/Service";>
<mapping name="ail:ResultImpl">
<!-- ignore succes property. Is determined by errorResult
value. -->
<property name="succes" ignore="true"/>
<!-- global -->
<property name="errorResult" class="java.util.Hashtable"
keyType="java.lang.String"
componentType="java.lang.String" />
<property name="result" class="java.util.Hashtable"
keyType="java.lang.String"
componentType="java.lang.Object" />
</mapping>
</mappings>
When the server returns a result object containing a Hashtable where the value
is a List<UoCode>, Aegis somehow returns the List as an ArrayOfString. See XML
below:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
<soap:Body>
<listCodesResponse xmlns="http://www.aegon.com/ail/spil/Service";>
<out xmlns="http://www.aegon.com/ail/spil/Service";
xsi:type="ResultImpl">
<errorResult xsi:nil="true"></errorResult>
<result>
<entry>
<key xsi:type="xsd:string">VoCodeList</key>
<value xsi:type="ArrayOfString">
<string xsi:type="UoCode">
<code>code1</code>
<description>this is code 1</description>
<language>nl</language>
</string>
</value>
</entry>
</result>
</out>
</listCodesResponse>
</soap:Body></soap:Envelope>
On the client, when receiving this xml, a StackOverflowException occurs. As
soon as it reaches ObjectType.readObject( ..), this method keeps calling itself.
To workaround this problem, I created the ResultStringListUoCode object which
extends ResultImpl and created a binding for this object which specifies the
result property to be a Hashtable of type <String,List<UoCode>>.
ResultStringListUoCode binding:
<mappings xmlns:ail="http://www.aegon.com/ail/spil/Service";>
<mapping name="ail:ResultStringListUoCode">
<property name="result" class="java.util.Hashtable"
keyType="java.lang.String"
componentType="#codes" />
<component name="codes" class="java.util.List"
componentType="nl.aegon.spilus.code.UoCode" />
</mapping>
</mappings>
The WSDL however does NOT show the result property as defined in the
ResultStringListUoCode binding, but still shows the binding of the parent class
ResultImpl. See WSDL fragment:
....
<xsd:complexType name="ResultStringListUoCode">
<xsd:complexContent>
<xsd:extension base="tns:ResultImpl"/>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="ResultImpl">
<xsd:sequence>
<xsd:element minOccurs="0" name="errorResult" nillable="true"
type="tns:string2stringMap"/>
<xsd:element minOccurs="0" name="result" nillable="true"
type="tns:anyType2anyTypeMap"/>
</xsd:sequence>
</xsd:complexType>
....
Because the ResultStringListUoCode binding is not used, the List<UoCode> object
is still returned as a ArrayOfString like in the XML above while the xsi:type
is ResultStringListUoCode. And therefore the client still has a
StackOverflowException reading the XML response.
So there are really 2 problems :
1. If a Map value is a List of Object's, it is returned as an ArrayOfString
(which causes StackOverflowException on client)
2. A subclass property defined in a binding is not used for WSDL and XML
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
