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