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 "Bill Mitchell (JIRA)" <ji...@apache.org> on 2008/01/28 03:49:35 UTC

[jira] Created: (AXIS2C-936) On incomplete response message, the client receives response data for the elements up to the error, but no indication of the error

On incomplete response message, the client receives response data for the elements up to the error, but no indication of the error
----------------------------------------------------------------------------------------------------------------------------------

                 Key: AXIS2C-936
                 URL: https://issues.apache.org/jira/browse/AXIS2C-936
             Project: Axis2-C
          Issue Type: Bug
          Components: code generation
    Affects Versions: Current (Nightly)
         Environment: Windows XP, Visual Studio 2005, libxml or guththila, libcurl
            Reporter: Bill Mitchell


If the SOAP response message to the client is incomplete, i.e., there is an EOF indication in the middle of the message, the client receives an object containing the elements that could be deserialized from the message, with no indication that the message is incomplete.  Clearly, the impact is that the client may act on the partial message, with no indication anywhere that data was lost.  

I considered whether this could be fixed in svc_client.c.  Although it appears with the debugger that the message is usually complete when at the end of axis2_svc_client_send_receive_with_op_qname(), this appears to be an accident of the fact that the lower level code looks for a soap fault in the soap body, and a SOAP 1.1 response does not have a fault in the body so the entire body is scanned first looking for the fault.  I believe the intent is that the response be returned without scanning all of the tokens in the body.   So it must be the responsibility of the generated stubs to check that all the data is processed when deserializing the elements.  

At the end of the deserialize method for the response message, there is code like the following:
     if(AXIS2_FAILURE ==  status)
     {
         AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "failed in setting the value for getExemplarResponse ");
         if(element_qname)
         {
             axutil_qname_free(element_qname, env);
         }
         return AXIS2_FAILURE;
     }
  }

  else if(!dont_care_minoccurs)
  {
      if(element_qname)
      {
          axutil_qname_free(element_qname, env);
      }
      /* this is not a nillable element*/
      AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "non nillable or minOuccrs != 0 element getExemplarResponse missing");
      return AXIS2_FAILURE;
  }

My suggestion is that an additional test for node complete be added similar to this:
     if(AXIS2_FAILURE ==  status)
     {
         AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "failed in setting the value for getExemplarResponse ");
         ...
     }
     if(axiom_node_is_complete(current_node, env) == AXIS2_FALSE)
     {
         AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "failed to scan entire element getExemplarResponse ");
         if(element_qname)
         {
             axutil_qname_free(element_qname, env);
         }
         return AXIS2_FAILURE;
     }
  }

  else if(!dont_care_minoccurs)
  ...

It would probably be reasonable and safe to do this as part of all the generated deserialize routines.  But in testing it appears sufficient to do this in the outermost response element routine, as this assures an error is returned to the client if the response message is incomplete.



-- 
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] Updated: (AXIS2C-936) On incomplete response message, the client receives response data for the elements up to the error, but no indication of the error

Posted by "Senaka Fernando (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/AXIS2C-936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Senaka Fernando updated AXIS2C-936:
-----------------------------------

    Fix Version/s:     (was: 1.3.0)

Can't Fix within 1.3.0 time frame.

> On incomplete response message, the client receives response data for the elements up to the error, but no indication of the error
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: AXIS2C-936
>                 URL: https://issues.apache.org/jira/browse/AXIS2C-936
>             Project: Axis2-C
>          Issue Type: Bug
>          Components: code generation
>    Affects Versions: Current (Nightly)
>         Environment: Windows XP, Visual Studio 2005, libxml or guththila, libcurl
>            Reporter: Bill Mitchell
>         Attachments: TemplateSource.diff
>
>
> If the SOAP response message to the client is incomplete, i.e., there is an EOF indication in the middle of the message, the client receives an object containing the elements that could be deserialized from the message, with no indication that the message is incomplete.  Clearly, the impact is that the client may act on the partial message, with no indication anywhere that data was lost.  
> I considered whether this could be fixed in svc_client.c.  Although it appears with the debugger that the message is usually complete when at the end of axis2_svc_client_send_receive_with_op_qname(), this appears to be an accident of the fact that the lower level code looks for a soap fault in the soap body, and a SOAP 1.1 response does not have a fault in the body so the entire body is scanned first looking for the fault.  I believe the intent is that the response be returned without scanning all of the tokens in the body.   So it must be the responsibility of the generated stubs to check that all the data is processed when deserializing the elements.  
> At the end of the deserialize method for the response message, there is code like the following:
>      if(AXIS2_FAILURE ==  status)
>      {
>          AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "failed in setting the value for getExemplarResponse ");
>          if(element_qname)
>          {
>              axutil_qname_free(element_qname, env);
>          }
>          return AXIS2_FAILURE;
>      }
>   }
>   else if(!dont_care_minoccurs)
>   {
>       if(element_qname)
>       {
>           axutil_qname_free(element_qname, env);
>       }
>       /* this is not a nillable element*/
>       AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "non nillable or minOuccrs != 0 element getExemplarResponse missing");
>       return AXIS2_FAILURE;
>   }
> My suggestion is that an additional test for node complete be added similar to this:
>      if(AXIS2_FAILURE ==  status)
>      {
>          AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "failed in setting the value for getExemplarResponse ");
>          ...
>      }
>      if(axiom_node_is_complete(current_node, env) == AXIS2_FALSE)
>      {
>          AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "failed to scan entire element getExemplarResponse ");
>          if(element_qname)
>          {
>              axutil_qname_free(element_qname, env);
>          }
>          return AXIS2_FAILURE;
>      }
>   }
>   else if(!dont_care_minoccurs)
>   ...
> It would probably be reasonable and safe to do this as part of all the generated deserialize routines.  But in testing it appears sufficient to do this in the outermost response element routine, as this assures an error is returned to the client if the response message is incomplete.

-- 
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] Commented: (AXIS2C-936) On incomplete response message, the client receives response data for the elements up to the error, but no indication of the error

Posted by "Senaka Fernando (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/AXIS2C-936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575797#action_12575797 ] 

Senaka Fernando commented on AXIS2C-936:
----------------------------------------

Devs,

This seems to be an easy fix. Thoughts?

Regards,
Senaka

> On incomplete response message, the client receives response data for the elements up to the error, but no indication of the error
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: AXIS2C-936
>                 URL: https://issues.apache.org/jira/browse/AXIS2C-936
>             Project: Axis2-C
>          Issue Type: Bug
>          Components: code generation
>    Affects Versions: Current (Nightly)
>         Environment: Windows XP, Visual Studio 2005, libxml or guththila, libcurl
>            Reporter: Bill Mitchell
>         Attachments: TemplateSource.diff
>
>
> If the SOAP response message to the client is incomplete, i.e., there is an EOF indication in the middle of the message, the client receives an object containing the elements that could be deserialized from the message, with no indication that the message is incomplete.  Clearly, the impact is that the client may act on the partial message, with no indication anywhere that data was lost.  
> I considered whether this could be fixed in svc_client.c.  Although it appears with the debugger that the message is usually complete when at the end of axis2_svc_client_send_receive_with_op_qname(), this appears to be an accident of the fact that the lower level code looks for a soap fault in the soap body, and a SOAP 1.1 response does not have a fault in the body so the entire body is scanned first looking for the fault.  I believe the intent is that the response be returned without scanning all of the tokens in the body.   So it must be the responsibility of the generated stubs to check that all the data is processed when deserializing the elements.  
> At the end of the deserialize method for the response message, there is code like the following:
>      if(AXIS2_FAILURE ==  status)
>      {
>          AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "failed in setting the value for getExemplarResponse ");
>          if(element_qname)
>          {
>              axutil_qname_free(element_qname, env);
>          }
>          return AXIS2_FAILURE;
>      }
>   }
>   else if(!dont_care_minoccurs)
>   {
>       if(element_qname)
>       {
>           axutil_qname_free(element_qname, env);
>       }
>       /* this is not a nillable element*/
>       AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "non nillable or minOuccrs != 0 element getExemplarResponse missing");
>       return AXIS2_FAILURE;
>   }
> My suggestion is that an additional test for node complete be added similar to this:
>      if(AXIS2_FAILURE ==  status)
>      {
>          AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "failed in setting the value for getExemplarResponse ");
>          ...
>      }
>      if(axiom_node_is_complete(current_node, env) == AXIS2_FALSE)
>      {
>          AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "failed to scan entire element getExemplarResponse ");
>          if(element_qname)
>          {
>              axutil_qname_free(element_qname, env);
>          }
>          return AXIS2_FAILURE;
>      }
>   }
>   else if(!dont_care_minoccurs)
>   ...
> It would probably be reasonable and safe to do this as part of all the generated deserialize routines.  But in testing it appears sufficient to do this in the outermost response element routine, as this assures an error is returned to the client if the response message is incomplete.

-- 
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] Commented: (AXIS2C-936) On incomplete response message, the client receives response data for the elements up to the error, but no indication of the error

Posted by "Bill Mitchell (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/AXIS2C-936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563044#action_12563044 ] 

Bill Mitchell commented on AXIS2C-936:
--------------------------------------

Looking at this again in the log, it would be more clear if the error message read something like:
"element getExemplarResponse is not complete".  

> On incomplete response message, the client receives response data for the elements up to the error, but no indication of the error
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: AXIS2C-936
>                 URL: https://issues.apache.org/jira/browse/AXIS2C-936
>             Project: Axis2-C
>          Issue Type: Bug
>          Components: code generation
>    Affects Versions: Current (Nightly)
>         Environment: Windows XP, Visual Studio 2005, libxml or guththila, libcurl
>            Reporter: Bill Mitchell
>
> If the SOAP response message to the client is incomplete, i.e., there is an EOF indication in the middle of the message, the client receives an object containing the elements that could be deserialized from the message, with no indication that the message is incomplete.  Clearly, the impact is that the client may act on the partial message, with no indication anywhere that data was lost.  
> I considered whether this could be fixed in svc_client.c.  Although it appears with the debugger that the message is usually complete when at the end of axis2_svc_client_send_receive_with_op_qname(), this appears to be an accident of the fact that the lower level code looks for a soap fault in the soap body, and a SOAP 1.1 response does not have a fault in the body so the entire body is scanned first looking for the fault.  I believe the intent is that the response be returned without scanning all of the tokens in the body.   So it must be the responsibility of the generated stubs to check that all the data is processed when deserializing the elements.  
> At the end of the deserialize method for the response message, there is code like the following:
>      if(AXIS2_FAILURE ==  status)
>      {
>          AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "failed in setting the value for getExemplarResponse ");
>          if(element_qname)
>          {
>              axutil_qname_free(element_qname, env);
>          }
>          return AXIS2_FAILURE;
>      }
>   }
>   else if(!dont_care_minoccurs)
>   {
>       if(element_qname)
>       {
>           axutil_qname_free(element_qname, env);
>       }
>       /* this is not a nillable element*/
>       AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "non nillable or minOuccrs != 0 element getExemplarResponse missing");
>       return AXIS2_FAILURE;
>   }
> My suggestion is that an additional test for node complete be added similar to this:
>      if(AXIS2_FAILURE ==  status)
>      {
>          AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "failed in setting the value for getExemplarResponse ");
>          ...
>      }
>      if(axiom_node_is_complete(current_node, env) == AXIS2_FALSE)
>      {
>          AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "failed to scan entire element getExemplarResponse ");
>          if(element_qname)
>          {
>              axutil_qname_free(element_qname, env);
>          }
>          return AXIS2_FAILURE;
>      }
>   }
>   else if(!dont_care_minoccurs)
>   ...
> It would probably be reasonable and safe to do this as part of all the generated deserialize routines.  But in testing it appears sufficient to do this in the outermost response element routine, as this assures an error is returned to the client if the response message is incomplete.

-- 
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] Updated: (AXIS2C-936) On incomplete response message, the client receives response data for the elements up to the error, but no indication of the error

Posted by "Bill Mitchell (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/AXIS2C-936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bill Mitchell updated AXIS2C-936:
---------------------------------

    Attachment: TemplateSource.diff

Looking at the TemplateSource.xsl file, I think my suggested placement for this new code is not quite the right place.  It think it's adequate to do this only when deserializing the entire adb_object, so it is easier to place in the xsl where the adb object deserializing is invoked.  

See the attached TemplateSource.diff for a better suggested fix.  If the test for node complete is done immediately after storing the element pointer from deserialization, it can fit into the normal error flow of testing the status, freeing the qname, and returning the failure, without risking a memory leak from building the node and not storing it.  

As before, I've generated this fix by inspection of the .xsl file, but I've not yet created the Java build environment to test the modified .xsl.  I have tested hand modified versions of the generated stubs to verify that they diagnose the error when the message is incomplete.  

> On incomplete response message, the client receives response data for the elements up to the error, but no indication of the error
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: AXIS2C-936
>                 URL: https://issues.apache.org/jira/browse/AXIS2C-936
>             Project: Axis2-C
>          Issue Type: Bug
>          Components: code generation
>    Affects Versions: Current (Nightly)
>         Environment: Windows XP, Visual Studio 2005, libxml or guththila, libcurl
>            Reporter: Bill Mitchell
>             Fix For: 1.3.0
>
>         Attachments: TemplateSource.diff
>
>
> If the SOAP response message to the client is incomplete, i.e., there is an EOF indication in the middle of the message, the client receives an object containing the elements that could be deserialized from the message, with no indication that the message is incomplete.  Clearly, the impact is that the client may act on the partial message, with no indication anywhere that data was lost.  
> I considered whether this could be fixed in svc_client.c.  Although it appears with the debugger that the message is usually complete when at the end of axis2_svc_client_send_receive_with_op_qname(), this appears to be an accident of the fact that the lower level code looks for a soap fault in the soap body, and a SOAP 1.1 response does not have a fault in the body so the entire body is scanned first looking for the fault.  I believe the intent is that the response be returned without scanning all of the tokens in the body.   So it must be the responsibility of the generated stubs to check that all the data is processed when deserializing the elements.  
> At the end of the deserialize method for the response message, there is code like the following:
>      if(AXIS2_FAILURE ==  status)
>      {
>          AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "failed in setting the value for getExemplarResponse ");
>          if(element_qname)
>          {
>              axutil_qname_free(element_qname, env);
>          }
>          return AXIS2_FAILURE;
>      }
>   }
>   else if(!dont_care_minoccurs)
>   {
>       if(element_qname)
>       {
>           axutil_qname_free(element_qname, env);
>       }
>       /* this is not a nillable element*/
>       AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "non nillable or minOuccrs != 0 element getExemplarResponse missing");
>       return AXIS2_FAILURE;
>   }
> My suggestion is that an additional test for node complete be added similar to this:
>      if(AXIS2_FAILURE ==  status)
>      {
>          AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "failed in setting the value for getExemplarResponse ");
>          ...
>      }
>      if(axiom_node_is_complete(current_node, env) == AXIS2_FALSE)
>      {
>          AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "failed to scan entire element getExemplarResponse ");
>          if(element_qname)
>          {
>              axutil_qname_free(element_qname, env);
>          }
>          return AXIS2_FAILURE;
>      }
>   }
>   else if(!dont_care_minoccurs)
>   ...
> It would probably be reasonable and safe to do this as part of all the generated deserialize routines.  But in testing it appears sufficient to do this in the outermost response element routine, as this assures an error is returned to the client if the response message is incomplete.

-- 
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] Updated: (AXIS2C-936) On incomplete response message, the client receives response data for the elements up to the error, but no indication of the error

Posted by "Senaka Fernando (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/AXIS2C-936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Senaka Fernando updated AXIS2C-936:
-----------------------------------

    Fix Version/s: 1.3.0

Hi all,

I believe that we can fix this issue for 1.3.0, as there are folks working on code generation.

Regards,
Senaka

> On incomplete response message, the client receives response data for the elements up to the error, but no indication of the error
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: AXIS2C-936
>                 URL: https://issues.apache.org/jira/browse/AXIS2C-936
>             Project: Axis2-C
>          Issue Type: Bug
>          Components: code generation
>    Affects Versions: Current (Nightly)
>         Environment: Windows XP, Visual Studio 2005, libxml or guththila, libcurl
>            Reporter: Bill Mitchell
>             Fix For: 1.3.0
>
>
> If the SOAP response message to the client is incomplete, i.e., there is an EOF indication in the middle of the message, the client receives an object containing the elements that could be deserialized from the message, with no indication that the message is incomplete.  Clearly, the impact is that the client may act on the partial message, with no indication anywhere that data was lost.  
> I considered whether this could be fixed in svc_client.c.  Although it appears with the debugger that the message is usually complete when at the end of axis2_svc_client_send_receive_with_op_qname(), this appears to be an accident of the fact that the lower level code looks for a soap fault in the soap body, and a SOAP 1.1 response does not have a fault in the body so the entire body is scanned first looking for the fault.  I believe the intent is that the response be returned without scanning all of the tokens in the body.   So it must be the responsibility of the generated stubs to check that all the data is processed when deserializing the elements.  
> At the end of the deserialize method for the response message, there is code like the following:
>      if(AXIS2_FAILURE ==  status)
>      {
>          AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "failed in setting the value for getExemplarResponse ");
>          if(element_qname)
>          {
>              axutil_qname_free(element_qname, env);
>          }
>          return AXIS2_FAILURE;
>      }
>   }
>   else if(!dont_care_minoccurs)
>   {
>       if(element_qname)
>       {
>           axutil_qname_free(element_qname, env);
>       }
>       /* this is not a nillable element*/
>       AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "non nillable or minOuccrs != 0 element getExemplarResponse missing");
>       return AXIS2_FAILURE;
>   }
> My suggestion is that an additional test for node complete be added similar to this:
>      if(AXIS2_FAILURE ==  status)
>      {
>          AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "failed in setting the value for getExemplarResponse ");
>          ...
>      }
>      if(axiom_node_is_complete(current_node, env) == AXIS2_FALSE)
>      {
>          AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "failed to scan entire element getExemplarResponse ");
>          if(element_qname)
>          {
>              axutil_qname_free(element_qname, env);
>          }
>          return AXIS2_FAILURE;
>      }
>   }
>   else if(!dont_care_minoccurs)
>   ...
> It would probably be reasonable and safe to do this as part of all the generated deserialize routines.  But in testing it appears sufficient to do this in the outermost response element routine, as this assures an error is returned to the client if the response message is incomplete.

-- 
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] Assigned: (AXIS2C-936) On incomplete response message, the client receives response data for the elements up to the error, but no indication of the error

Posted by "Damitha Kumarage (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/AXIS2C-936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Damitha Kumarage reassigned AXIS2C-936:
---------------------------------------

    Assignee: Damitha Kumarage

> On incomplete response message, the client receives response data for the elements up to the error, but no indication of the error
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: AXIS2C-936
>                 URL: https://issues.apache.org/jira/browse/AXIS2C-936
>             Project: Axis2-C
>          Issue Type: Bug
>          Components: code generation
>    Affects Versions: Current (Nightly)
>         Environment: Windows XP, Visual Studio 2005, libxml or guththila, libcurl
>            Reporter: Bill Mitchell
>            Assignee: Damitha Kumarage
>         Attachments: TemplateSource.diff
>
>
> If the SOAP response message to the client is incomplete, i.e., there is an EOF indication in the middle of the message, the client receives an object containing the elements that could be deserialized from the message, with no indication that the message is incomplete.  Clearly, the impact is that the client may act on the partial message, with no indication anywhere that data was lost.  
> I considered whether this could be fixed in svc_client.c.  Although it appears with the debugger that the message is usually complete when at the end of axis2_svc_client_send_receive_with_op_qname(), this appears to be an accident of the fact that the lower level code looks for a soap fault in the soap body, and a SOAP 1.1 response does not have a fault in the body so the entire body is scanned first looking for the fault.  I believe the intent is that the response be returned without scanning all of the tokens in the body.   So it must be the responsibility of the generated stubs to check that all the data is processed when deserializing the elements.  
> At the end of the deserialize method for the response message, there is code like the following:
>      if(AXIS2_FAILURE ==  status)
>      {
>          AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "failed in setting the value for getExemplarResponse ");
>          if(element_qname)
>          {
>              axutil_qname_free(element_qname, env);
>          }
>          return AXIS2_FAILURE;
>      }
>   }
>   else if(!dont_care_minoccurs)
>   {
>       if(element_qname)
>       {
>           axutil_qname_free(element_qname, env);
>       }
>       /* this is not a nillable element*/
>       AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "non nillable or minOuccrs != 0 element getExemplarResponse missing");
>       return AXIS2_FAILURE;
>   }
> My suggestion is that an additional test for node complete be added similar to this:
>      if(AXIS2_FAILURE ==  status)
>      {
>          AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "failed in setting the value for getExemplarResponse ");
>          ...
>      }
>      if(axiom_node_is_complete(current_node, env) == AXIS2_FALSE)
>      {
>          AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "failed to scan entire element getExemplarResponse ");
>          if(element_qname)
>          {
>              axutil_qname_free(element_qname, env);
>          }
>          return AXIS2_FAILURE;
>      }
>   }
>   else if(!dont_care_minoccurs)
>   ...
> It would probably be reasonable and safe to do this as part of all the generated deserialize routines.  But in testing it appears sufficient to do this in the outermost response element routine, as this assures an error is returned to the client if the response message is incomplete.

-- 
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