You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by "Frank Huebbers (JIRA)" <ji...@apache.org> on 2008/01/19 01:56:35 UTC
[jira] Created: (AXIS2C-921) Parsing of SOAP message with a
nillable member array of size 0 causes incorrect parsing
Parsing of SOAP message with a nillable member array of size 0 causes incorrect parsing
---------------------------------------------------------------------------------------
Key: AXIS2C-921
URL: https://issues.apache.org/jira/browse/AXIS2C-921
Project: Axis2-C
Issue Type: Bug
Components: wsdl2c tool
Affects Versions: Current (Nightly)
Reporter: Frank Huebbers
Hi,
I have come across a new bug which involves the parsing/deserialization of a SOAP message with nillable array types. The setup is as follows:
I have a return type with two array elements and with another element which is not nillable followed right after as described in my wsdl file as follows:
<element name="boolType0" nillable="false" type="xsd:boolean" />
<element name="arrayType1" nillable="true" minOccurs="0" maxOccurs="unbounded" type="xsd:string" />
<element name="arrayType2" nillable="true" minOccurs="0" maxOccurs="unbounded" type="xsd:string" />
<element name="boolType1" nillable="false" type="xsd:boolean" />
<element name="boolType2" nillable="false" type="xsd:boolean" />
<element name="boolType3" nillable="false" type="xsd:boolean" />
In my particular example, the arrayType1 and arrayTyp2 turn out to be null. After trying to deserialize arrayType1 and arrayType2, however, the "current_node" which Axis2/c tries to parse next is set to "boolType2." In other words, the current_node is two "siblings" ahead of what it should be.
When examining the generated code, I found out what the cause of the problem is. Specifically, I get the following for loop code snippet:
for (i = 0, sequence_broken = 0, tmp_node = current_node = axiom_node_get_next_sibling(current_node, env); current_node != NULL; current_node = axiom_node_get_next_sibling(current_node, env))
{
if(axiom_node_get_node_type(current_node, env) != AXIOM_ELEMENT)
{
continue;
}
// more code
}
current_node = tmp_node;
When examining the code, we can see that at the beginning of the loop, the next sibling to the current node is retrieved and stored both in tmp_node and currrent_node. If, as is the case in my example, the type is null, this means that the current_node will not be reset to the previous value. The way we can get arround this is by introducing a new variable (tmpArray_node) and doing the following operation before the for loop:
element_found = AXIS2_FALSE;
tmpArray_node = current_node;
then, after the loop we do the following operation:
if (AXIS2_TRUE == element_found)
{
current_node = tmp_node;
}
else
{
current_node = tmpArray_node;
}
Note that this assumes that the "element_found" variable is set when the array type has at least one member. This is already the case in the generated code (not shown in this example). By making the additions above, I was able to get the generated code to parse the SOAP message correctly.
Frank
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Resolved: (AXIS2C-921) Parsing of SOAP message with a
nillable member array of size 0 causes incorrect parsing
Posted by "Dimuthu Gamage (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dimuthu Gamage resolved AXIS2C-921.
-----------------------------------
Resolution: Fixed
Please check the comment on
https://issues.apache.org/jira/browse/AXIS2C-920?focusedCommentId=12560656#action_12560656
I have attached a test case for the fix.
Thanks
> Parsing of SOAP message with a nillable member array of size 0 causes incorrect parsing
> ---------------------------------------------------------------------------------------
>
> Key: AXIS2C-921
> URL: https://issues.apache.org/jira/browse/AXIS2C-921
> Project: Axis2-C
> Issue Type: Bug
> Components: wsdl2c tool
> Affects Versions: Current (Nightly)
> Reporter: Frank Huebbers
>
> Hi,
> I have come across a new bug which involves the parsing/deserialization of a SOAP message with nillable array types. The setup is as follows:
> I have a return type with two array elements and with another element which is not nillable followed right after as described in my wsdl file as follows:
> <element name="boolType0" nillable="false" type="xsd:boolean" />
> <element name="arrayType1" nillable="true" minOccurs="0" maxOccurs="unbounded" type="xsd:string" />
> <element name="arrayType2" nillable="true" minOccurs="0" maxOccurs="unbounded" type="xsd:string" />
> <element name="boolType1" nillable="false" type="xsd:boolean" />
> <element name="boolType2" nillable="false" type="xsd:boolean" />
> <element name="boolType3" nillable="false" type="xsd:boolean" />
> In my particular example, the arrayType1 and arrayTyp2 turn out to be null. After trying to deserialize arrayType1 and arrayType2, however, the "current_node" which Axis2/c tries to parse next is set to "boolType2." In other words, the current_node is two "siblings" ahead of what it should be.
> When examining the generated code, I found out what the cause of the problem is. Specifically, I get the following for loop code snippet:
> for (i = 0, sequence_broken = 0, tmp_node = current_node = axiom_node_get_next_sibling(current_node, env); current_node != NULL; current_node = axiom_node_get_next_sibling(current_node, env))
> {
> if(axiom_node_get_node_type(current_node, env) != AXIOM_ELEMENT)
> {
> continue;
> }
> // more code
> }
> current_node = tmp_node;
> When examining the code, we can see that at the beginning of the loop, the next sibling to the current node is retrieved and stored both in tmp_node and currrent_node. If, as is the case in my example, the type is null, this means that the current_node will not be reset to the previous value. The way we can get arround this is by introducing a new variable (tmpArray_node) and doing the following operation before the for loop:
> element_found = AXIS2_FALSE;
> tmpArray_node = current_node;
> then, after the loop we do the following operation:
> if (AXIS2_TRUE == element_found)
> {
> current_node = tmp_node;
> }
> else
> {
> current_node = tmpArray_node;
> }
> Note that this assumes that the "element_found" variable is set when the array type has at least one member. This is already the case in the generated code (not shown in this example). By making the additions above, I was able to get the generated code to parse the SOAP message correctly.
> Frank
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org