axis-c-dev mailing list archives

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. 
>>>     
>>
>>   
>