axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank Huebbers (JIRA)" <>
Subject [jira] Created: (AXIS2C-921) Parsing of SOAP message with a nillable member array of size 0 causes incorrect parsing
Date Sat, 19 Jan 2008 00:56:35 GMT
Parsing of SOAP message with a nillable member array of size 0 causes incorrect parsing

                 Key: AXIS2C-921
             Project: Axis2-C
          Issue Type: Bug
          Components: wsdl2c tool
    Affects Versions: Current (Nightly)
            Reporter: Frank Huebbers


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)
// 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;                              
                                   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


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:
For additional commands, e-mail:

View raw message