Franz,
The current "fix" in svn does not work with attributes. However, I plan
on putting in a revamped fix just after I finish simple attributes with
simple type jira, which is consuming my immediate energy and time.
Nadir K. Amra
Franz Fehringer <[EMAIL PROTECTED]> wrote on 12/18/2006 03:03:49 AM:
> Hello Nadir,
>
> I cannot currently do svn up, because of conflicting fixes for
> AXISCPP-991 (one by you and one by me).
> How do these fixes compare?
> Does your fix work (for START_END_ELEMENT) in the presence of
attributes?
> Will there be a revamped more complete fix in the not too distant
future?
>
> Greetings
>
> Franz
>
>
> Franz Fehringer schrieb:
> 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
>
>
> nadir amra (JIRA) schrieb:
> [ http://issues.apache.org/jira/browse/AXISCPP-991?
> page=comments#action_12454432 ]
>
> nadir amra commented on AXISCPP-991:
> ------------------------------------
>
> I put a temporary fix so that if start_end tag was specified with no
> attributes (which I am hoping is the prevalent scenario), then things
work.
>
> Scott, I will look into your fix. But I think the end-game should
> be in the generated code, where it should invoke a new API to
> determine if the current node is a start-end tag, in which case it
> would simply return.
>
>
> 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.
>
>
>
>
> [attachment "feh.vcf" deleted by Nadir Amra/Rochester/IBM]
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
