[ http://issues.apache.org/jira/browse/AXISCPP-991?page=comments#action_12459322 ] Franz Fehringer commented on AXISCPP-991: -----------------------------------------
I think my current solution only works, if at most one optional subelement is missing. The case of multiple optional/missing subelements could perhaps be settled by omitting the resetting of m_bStartEndElement at the beginning of peek() and relying on the unconditional reset when entering next() for the (END_ELEMENT,START_END_ELEMENT) node. > Deserializing complex type broken when start-end element tag is encountered > --------------------------------------------------------------------------- > > Key: AXISCPP-991 > URL: http://issues.apache.org/jira/browse/AXISCPP-991 > Project: Axis-C++ > Issue Type: Bug > Components: Client - Deserialization > Reporter: nadir amra > Assigned To: nadir amra > > If a complex type defined as: > <s:complexType name="SortR"> > <s:sequence> > <s:element minOccurs="0" maxOccurs="1" name="ListMsg" > type="tns:ArrayOfMsgS" /> > <s:element minOccurs="0" maxOccurs="1" name="DateMed" > type="s:string" /> > <s:element minOccurs="1" maxOccurs="1" name="NumberMed" > type="s:int" /> > </s:sequence> > </s:complexType> > And the response comes back as: > <SortRResult> > <ListMsg/> > <DateMed>2006-11-10</DateMed> > <NumberMed>123456</NumberMed> > . > . > The deserialization of ListMsg does not recognize the fact that empty element > was passed and thus attempts to parse the subsequent data as if it was part > of ListMsg. -- 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
