[
http://issues.apache.org/jira/browse/AXISCPP-991?page=comments#action_12459321
]
Franz Fehringer commented on AXISCPP-991:
-----------------------------------------
Hello Nadir,
I made a fix for this problen which works also in the presence of attributes.
To this end i invented an additional member m_bStartEndElement in
XMLParserXerces.
It is set to true if (START_ELEMENT,START_END_ELEMENT) is detected in next().
The code at the end of XMLParserXerces.cpp now looks
else
{
if (elem->m_type == START_ELEMENT && elem->m_type2 ==
START_END_ELEMENT)
m_bStartEndElement = true;
return elem;
}
}
return NULL;
}
At the beginning of peek() i check for m_bStartEndElement:
if (m_bStartEndElement)
{
m_bStartEndElement = false;
return "";
}
For this to really work i had to initialize m_bStartEndElement to false in the
constructors ans also unconditionally set it to false at the very beginning of
both next() and anyNext() (i am not sure if both are necessary and if i should
check for (START_ELEMENT,START_END_ELEMENT) in anyNext() also).
Now cases like
<tri tra="trö"/>
where an optional subelement is missing (and peeked for in the deserializer)
are processed correctly.
Best regards
Franz
> 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]
