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