You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-user@axis.apache.org by "Dr. Florian Steinborn" <fp...@gmx.de> on 2007/08/08 00:42:17 UTC
[WSDL2C] Bug in C - ServerStubs - Unexpected Subelement
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: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org
Re: [WSDL2C] Bug in C - ServerStubs - Unexpected Subelement
Posted by Dimuthu Gamage <di...@gmail.com>.
hi,
This is an error in the serialize logic and the deserialize logic.
The problem arises because adb structures are generated for
all the elements (+for complex types), and there are two ways to
define an element
1. <xs:element name="matrixAdd" type="ns1:matrixAddType">
</xs:element>
<xs:complexType name="matrixAddType">
<xs:sequence>
<xs:element minOccurs="0" name="param0" nillable="true"
type="ns1:Matrix"/>
<xs:element minOccurs="0" name="param1" nillable="true"
type="ns1:Matrix"/>
</xs:sequence>
</xs:complexType>
and
2. <xs:element name="matrixAdd">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="param0"
nillable="true" type="ns1:Matrix"/>
<xs:element minOccurs="0" name="param1"
nillable="true" type="ns1:Matrix"/>
</xs:sequence>
</xs:complexType>
</xs:element>
If the above mentioned "if(has_parent)" check is not done, in the
first case there are two matrixAdd element are
generated in the xml one inside other. So to distinguish these two
cases, we have to use the @anon flag in the
adb templates.
I have done several tests and seems the changes are working.
used wsdls
used wsdls
Adder.wsdl - all outer elements have anonymous types
Adder2.wsdl - Outer elements have anonyous and named types
Adder3.wsdl - All having anonymous type
Attachment consists of the test code for (both stub and skel)
step1 - when if(has_parent) is used in line 1575 -- all outer elements
have anonymous types
step2 - when if(!has_parent) is used
step3 - when the if is removed
step4 - when the if is removed and MatrixAdd has a named type (not a
anonymous type)
step5 - when the @anon is used with all outer elements have anonymous types
step6 - when the @anon is used with outer elements have anonymous
types and named types
step7 - when the @anon is used with all having anonymous types -Adder3.wsdl
Thanks
Dimuthu
On 8/9/07, Dr. Florian Steinborn <fl...@drb.insel.de> wrote:
> Hi Samisa
>
> > Looks like a logic error in the generated code. I could change the style
> > sheet logic to include this.
> > However, I would like to have a test case to ensure the change works.
> >
>
> attached you find a WSDL and the generated C code with the error. This
> could make it easier to see your change works.
>
> Thanks,
> Flori
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-user-help@ws.apache.org
>
>
Re: [WSDL2C] Bug in C - ServerStubs - Unexpected Subelement
Posted by "Dr. Florian Steinborn" <fl...@drb.insel.de>.
Hi Samisa
> Looks like a logic error in the generated code. I could change the style
> sheet logic to include this.
> However, I would like to have a test case to ensure the change works.
>
attached you find a WSDL and the generated C code with the error. This
could make it easier to see your change works.
Thanks,
Flori
Re: [WSDL2C] Bug in C - ServerStubs - Unexpected Subelement
Posted by Samisa Abeysinghe <sa...@wso2.com>.
Looks like a logic error in the generated code. I could change the style
sheet logic to include this.
However, I would like to have a test case to ensure the change works.
Samisa...
Dr. Florian Steinborn wrote:
> Hi,
>
> just to let you know what we did to temporarily bypass the problem:
>
> We added just one exclamation mark and it works:
>
> [...]
>
>> if(has_parent)
>> axutil_stream_write(stream, env, start_input_str,
>> start_input_str_len);
>
> changed to
>
> if(!has_parent)
> axutil_stream_write(stream, env, start_input_str,
> start_input_str_len);
>
> [...]
>
> Needless to say this is editing the generated source - the way we did
> not want to go.
>
> Thanks and greetings 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
>
>
--
Samisa Abeysinghe : <a href="http://wso2.org/projects/wsf/c">WSO2 Web Services Framework/C - Open source C library for providing and consuming Web services</a>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org
Re: [WSDL2C] Bug in C - ServerStubs - Unexpected Subelement
Posted by "Dr. Florian Steinborn" <fp...@gmx.de>.
Hi,
just to let you know what we did to temporarily bypass the problem:
We added just one exclamation mark and it works:
[...]
> if(has_parent)
> axutil_stream_write(stream, env, start_input_str,
> start_input_str_len);
changed to
if(!has_parent)
axutil_stream_write(stream, env, start_input_str,
start_input_str_len);
[...]
Needless to say this is editing the generated source - the way we did not
want to go.
Thanks and greetings 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