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, ¤t_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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
