axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dr. Florian Steinborn" <fpu...@gmx.de>
Subject [WSDL2C] Bug in C - ServerStubs - Unexpected Subelement
Date Tue, 07 Aug 2007 22:42:17 GMT
Hi folks,

I can hardly believe that we are the only ones to find out that the  
serverstubs generated by the latest nightly builds are not usable any  
more. But this is our conclusion after spending several hours on the  
problem and comparing newly generated code with older versions. I would be  
willing to raise a JIRA but first I would like to get your opinion on this.

The problem seems to be that the responses sent by the webserver in some  
cases are not formatted correctly. The result is an "unexpected element"  
fault caught by the client. I am sure you can easily regenerate the  
problem. Here is what we tried:

Consider a webservice that returns a structure of different (simple) data  
types (returning single simple types makes no problem). In our case it was  
something called "Dat" that can be understood by the follwing wsdl:

<xs:complexType name="Dat">
                 <xs:sequence>
                     <xs:element minOccurs="0" name="dl" type="xs:double"/>
                     <xs:element minOccurs="0" name="fl" type="xs:float"/>
                     <xs:element minOccurs="0" name="i" type="xs:int"/>
                     <xs:element minOccurs="0" name="str" nillable="true"  
type="x
                     <xs:element minOccurs="0" name="l" type="xs:long"/>
                     <xs:element minOccurs="0" name="s" type="xs:short"/>
                 </xs:sequence>
</xs:complexType>

We have a webservice that returns such an element.

When you create server stubs and execute the service you will run into a  
ADBException:

Caused by: org.apache.axis2.databinding.ADBException: Unexpected  
subelement dl
	at  
org.apache.ws.axis2.GetDatResponse$Factory.parse(GetDatResponse.java:440)
	... 30 more


Running the tcpmon shows what happens:



HTTP/1.1 200 OK^M
Content-Type: application/soap+xml;charset=UTF-8^M
Transfer-Encoding: chunked^M
90^M
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
<soapenv:Header>
</soapenv:Header>
<soapenv:Body>
<ns1:getDatResponse xmlns:ns1="http://ws.apache.org/axis2"  
xmlns:ns3="http://ws.apache.org/axis2/xsd">
<ns3:dl>1.100000</ns3:dl>
<ns3:fl>2.200000</ns3:fl>
<ns3:i>3</ns3:i>
<ns3:str>KETTE</ns3:str>
<ns3:l>4</ns3:l>
<ns3:s>5</ns3:s>
</ns1:getDatResponse>
</soapenv:Body>
</soapenv:Envelope>^M



The tokens "<ns1:return>" and "</ns1:return>" seem to be missing.

Earlier versions produced:

<soapenv:Envelope  
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
</soapenv:Header>
<soapenv:Body>
<ns1:getDatResponse xmlns:ns1="http://ws.apache.org/axis2/xsd">
<ns1:return>
<ns1:dl>1.100000</ns1:dl>
<ns1:fl>2.200000</ns1:fl>
<ns1:i>3</ns1:i>
<ns1:str>KETTE</ns1:str>
<ns1:l>4</ns1:l>
<ns1:s>5</ns1:s>
</ns1:return>
</ns1:getDatResponse>
</soapenv:Body>
</soapenv:Envelope>^M


As we found out, the problem lies in the generation of the methods inside
axis2_get<STRUCTTYPE>Response.c file.

Earlier versions of AXIS2 generated code like this in the "serialze"  
method:

[...]

if(has_parent)
{
  data_source = axiom_node_get_data_element(parent, env);
  if (!data_source)
     return NULL;
     stream = axiom_data_source_get_stream(data_source, env); /*assume  
parent is of type data source */
     if (!stream)
         return NULL;
         current_node = parent;
     }
     else
     {
        data_source = axiom_data_source_create(env, parent, &current_node);
        stream = axiom_data_source_get_stream(data_source, env);
     }

     /**
     * parsing return element
     */

     start_input_str = "<ns1:return>";
     start_input_str_len = axutil_strlen(start_input_str);
     end_input_str = "</ns1:return>";
     end_input_str_len = axutil_strlen(end_input_str);

     axutil_stream_write(stream, env, start_input_str, start_input_str_len);
     axis2_Dat_serialize( getDatResponse->attrib_return, env, current_node,  
AXIS2_TRUE);
     axutil_stream_write(stream, env, end_input_str, end_input_str_len);

[...]

As we can see the wanted element <ns1:return> is written unconditionally.

Not so the latest nightly build. It generates:

[...]
/**
  * parsing return element
  */
start_input_str = "<ns1:return  
xmlns:ns3=\"http://ws.apache.org/axis2/xsd\">";
start_input_str_len = axutil_strlen(start_input_str);
end_input_str = "</ns1:return>";
end_input_str_len = axutil_strlen(end_input_str);
if(has_parent)
   axutil_stream_write(stream, env, start_input_str, start_input_str_len);
adb_Dat_serialize( _getDatResponse->attrib_return, env, current_node,  
AXIS2_TRUE);
if(has_parent)
     axutil_stream_write(stream, env, end_input_str, end_input_str_len);


[...]

This seems to be wrong as the serialize-functions is always called with  
the parameter "has_parent" = FALSE. The result is the above mentioned  
error. It seems the blocks accidentially moved to another position during  
generation.

As far as we can see this renders the generated Axis-Services completely  
useless and again we wonder how others are working...

Please tell us if we have to raise a JIRA for this or if there is a way to  
bypass the problem (except editing all the generated sources).

Thanks a lot and good night from Berlin,

Flori

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org


Mime
View raw message