[ http://issues.apache.org/jira/browse/AXISCPP-250?page=all ] Chinthana Danapala closed AXISCPP-250: --------------------------------------
(Visible to axiscpp-developers) > Errors in handling minOccurs="0" (optional) elemnts in SOAP message > ------------------------------------------------------------------- > > Key: AXISCPP-250 > URL: http://issues.apache.org/jira/browse/AXISCPP-250 > Project: Axis-C++ > Type: Bug > Components: Serialization > Versions: 1.3 Final > Environment: All platforrms > Reporter: Samisa Abeysinghe > Assignee: Chinthana Danapala > Priority: Critical > Attachments: SOAP_message.txt, WS021A.wsdl > > The following is from the mailing list. See > http://marc.theaimsgroup.com/?t=109902729200001&r=1&w=2 for more information : > > All elements in the response have minOccurs="0", so they can be > omitted. Is this another issue? > Good point Adrian! I missed that :(. > This must be the reason that is causing the problem. > To my knowledge, WSDL2Ws tool does not deal with this correctly (I came > to this conclusion by > looking at the generated code for the WSDL). It expects all the > elements to be there, and throws > an error, if at least a single element is missing. > Also, the ordering of the element is very critical for the generated > code to work. > e.g. > param->names = (xsd__string_Array&)pIWSDZ->getBasicArray(XSD_STRING, > "names",0); > param->addrs = (xsd__string_Array&)pIWSDZ->getBasicArray(XSD_STRING, > "addrs",0); > param->xdirInd = pIWSDZ->getElementAsString("xdirInd",0); > param->noOfBillRecords = pIWSDZ->getElementAsInt("noOfBillRecords",0); > (the '0' parameters in above code indicates that namespace is NULL - it > must have used NULL > instead of 0) > If "xdirInd" is missing in the response, and "noOfBillRecords" is > present, > getElementAsString("xdirInd",0) call on the serializer will see that > next element is > "noOfBillRecords" and will error. > If we are looking for an optional element, we are doing a serious > mistake here (and thus this is a > serious bug) > The correct logic would be to > 1. Test if the element is opetional > if yes > 1.1. Test if the current element is what we are looking for > if yes > 1.1.1 return Success > if no > 1.1.2 Back track to point to the start of the elemnt and > return Success > if no > 1.2 return Failure > I hope the above algorithm does not violate the pull model we have. > Additionally, can we expect the SOAP message to have the elements in > the same order defined by the > WSDL? If yes (I think it is) we are OK. If not we have another bug :( -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
