Axis2-C
  1. Axis2-C
  2. AXIS2C-557

WSDL2C: generated adb code does not allow any elements to be omitted - too inflexible

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: Current (Nightly)
    • Fix Version/s: 1.1.0
    • Component/s: code generation
    • Labels:
      None
    • Environment:
      Windows XP

      Description

      I am using WSDL2C with adb data binding.

      The code that is generated requires all elements specified in the WSDL for a given web service call to be present. It should instead check the name of each node and allow some data elements to be omitted.

      Instead it generates code like the following, where it assumes the next node is the node it expects. It should check the name of the node and skip to the next expected node if the name does not match:

      /**

      • because elements are ordered this works fine
        */

      if( current_node != NULL)

      { current_node = AXIOM_NODE_GET_NEXT_SIBLING( current_node, env); }

      if ( current_node != NULL)
      {
      current_element = AXIOM_NODE_GET_DATA_ELEMENT( current_node, env);
      text_value = AXIOM_ELEMENT_GET_TEXT(current_element, env, current_node );

      Here it blindly gets the text_value and sets it into the field that it expects the value to be for. This means that all the nodes must be present or it will set the wrong values in the fields. So if new arguments are added to an object passed in the call, it will no longer be backwards compatible with clients that are using the older version of the WSDL.

      1. test2.wsdl
        4 kB
        Dave Meier

        Activity

        Hide
        Milinda Lakmal Pathirage added a comment -

        When the elements are ordered we don't have to check the name of the node. We only have to check if the element is nillable or minOccurs=0.
        This code part inside the Template will handle this situation:

        <xsl:if test="not(@nillable) and not(@minOccurs=0)">
        else

        { /** this is not a nillable element*/ AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "non nillable or minOuccrs != 0 element <xsl:value-of select="$propertyName"/> missing" " %d :: %s", env->error->error_number, AXIS2_ERROR_GET_MESSAGE(env->error)); return AXIS2_FAILURE; }

        </xsl:if>

        It is better if you can attach the WSDL to JIRA issue, then we can test it.

        Show
        Milinda Lakmal Pathirage added a comment - When the elements are ordered we don't have to check the name of the node. We only have to check if the element is nillable or minOccurs=0. This code part inside the Template will handle this situation: <xsl:if test="not(@nillable) and not(@minOccurs=0)"> else { /** this is not a nillable element*/ AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "non nillable or minOuccrs != 0 element <xsl:value-of select="$propertyName"/> missing" " %d :: %s", env->error->error_number, AXIS2_ERROR_GET_MESSAGE(env->error)); return AXIS2_FAILURE; } </xsl:if> It is better if you can attach the WSDL to JIRA issue, then we can test it.
        Hide
        Dave Meier added a comment -

        Test WSDL, showing the Note type which has two optional elements, called "title" and "note".

        Here's the scenario that the current code generation does not handle:

        A call is made to "SetNote" and in the note element, the "id", "modificationDateTime" and "accessType" are set, but "title" and "note" are not provided at all, since they are optional. So the xml coming in would have something like this:

        <note>
        <id>1</id>
        <modificationDateTime>0001-01-01T00:00:00</modificationDateTime>
        <accessType>ATTACHACCESS-DEFAULT</accessType>
        </note>

        Now, the parsing code will parse "id" correctly, then it will parse "title" as "0001-01-01T00:00:00" and will parse "note" as "ATTACHACCESS-DEFAULT". After that there are no nodes left, so an error will occur when it goes to parse "modificationDateTime".

        So, what I'm saying is the absence of optional elements in the XML should be supported. Since the node name is not checked, this scenario is not handled.

        With gSoap, it handles this kind of stuff really well, because I can even add new required elements and still have a client with an older WSDL call in and succeed. The gSoap generated code just fills in values based on what's in the XML and the values that aren't there get set to whatever the default values are.

        Show
        Dave Meier added a comment - Test WSDL, showing the Note type which has two optional elements, called "title" and "note". Here's the scenario that the current code generation does not handle: A call is made to "SetNote" and in the note element, the "id", "modificationDateTime" and "accessType" are set, but "title" and "note" are not provided at all, since they are optional. So the xml coming in would have something like this: <note> <id>1</id> <modificationDateTime>0001-01-01T00:00:00</modificationDateTime> <accessType>ATTACHACCESS-DEFAULT</accessType> </note> Now, the parsing code will parse "id" correctly, then it will parse "title" as "0001-01-01T00:00:00" and will parse "note" as "ATTACHACCESS-DEFAULT". After that there are no nodes left, so an error will occur when it goes to parse "modificationDateTime". So, what I'm saying is the absence of optional elements in the XML should be supported. Since the node name is not checked, this scenario is not handled. With gSoap, it handles this kind of stuff really well, because I can even add new required elements and still have a client with an older WSDL call in and succeed. The gSoap generated code just fills in values based on what's in the XML and the values that aren't there get set to whatever the default values are.
        Hide
        Dave Meier added a comment -

        The test2.wsdl shows the example I am describing.

        -Dave.

        Show
        Dave Meier added a comment - The test2.wsdl shows the example I am describing. -Dave.
        Hide
        Milinda Lakmal Pathirage added a comment -

        Thanks for the explanation. I'll look into this issue.

        Show
        Milinda Lakmal Pathirage added a comment - Thanks for the explanation. I'll look into this issue.
        Hide
        Samisa Abeysinghe added a comment -

        Fixed the Java tool's template to handle the case.

        Show
        Samisa Abeysinghe added a comment - Fixed the Java tool's template to handle the case.

          People

          • Assignee:
            Samisa Abeysinghe
            Reporter:
            Dave Meier
          • Votes:
            2 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development