axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Franz Fehringer <...@isogmbh.de>
Subject Re: [jira] Closed: (AXISCPP-991) Deserializing complex type broken when start-end element tag is encountered
Date Fri, 26 Jan 2007 08:32:57 GMT
Thanks Nadir,

I will come back to you, if i see any further problems (but not for the 
moment).

Cheers

Franz


Nadir Amra schrieb:
> Franz,
>
> I think it is needed to ensure that the node just peeked is kept around 
> for it to be consumed.  But peeking for a non-existant optional element 
> does not affect the state of the parser.  Sure it reads the next node, but 
> it is not consumed.   The peek'ed element is still available for 
> processing.  I think I have fixed your problem unless you think I missed 
> something?  I have created 2 tests, one returns the following response:
>
> <?xml version="1.0" encoding="utf-8"?> 
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 
> <soap:Body>
> <NewOperationResponse xmlns="http://startendelement.test.apache.org">      
>  
>       <Param_NewOperationResponse>
>         <ListInfoString />  
>         <SomeString>Testing start/end empty element</SomeString>   
>       </Param_NewOperationResponse>  
> </NewOperationResponse> 
> </soap:Body> 
> </soap:Envelope> 
>
> and the other (basically same response except empty element has 
> attributes) returns the following response:
>
> <?xml version="1.0" encoding="utf-8"?> 
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 
> <soap:Body>
> <NewOperationResponse xmlns="http://startendelement.test.apache.org">      
>  
>       <Param_NewOperationResponse>
>         <ListInfoString attributeB="attributeB-Value"/>   
>         <SomeString>Testing start/end empty element</SomeString>   
>       </Param_NewOperationResponse>  
> </NewOperationResponse> 
> </soap:Body> 
> </soap:Envelope> 
>
> If I am missing a test, let me know. 
>
> I think the peek() routine and peek flag can probably be removed if we 
> kept the node around for both Doc and RPC processing, but RPC processing 
> does not seem to be sensitive to whether the m_pNode is set or not.  It is 
> probably something that I will look into in the future.
>
> Nadir K. Amra
>
>
> Franz Fehringer <feh@isogmbh.de> wrote on 01/25/2007 04:08:25 AM:
>
>   
>> Hello Nadir,
>>
>> Since you are currently reworking this area of code, i woukd like to
>> come back with my issue/question below.
>> My concerns result from the fact, that peek()ing for a nonexistent 
>> optional elemen is not a noop (as it perhaps should be).
>> Rather it sets the member variable m_bPeeked (in the Xerces parser) 
>> to true, which in turn implies a tendency in the parser to advance 
>> faster (and depending on other factors perhaps too fast).
>> What i would like to ask you to do is
>> 1. Make a specific test case for my scenario.
>> 2. Analyze the reason for the presence of m_bPeeked.
>> Perhaps you can get rid of it in the course of your rework?
>> Cheers
>>
>> Franz
>>
>>
>> Nadir Amra schrieb: 
>> Hi Franz,
>>
>> While I did not specifically test for that scenario, I believe the 
>> solution will work.  The tests I put in tests the following type coming 
>>     
> in 
>   
>> as start/end element:
>>
>>       <s:complexType name="ArrayOfInfoString">
>>         <s:attribute name="attributeA" type="s:string" use="optional"/>
>>         <s:attribute name="attributeB" type="s:string" use="required"/>
>>         <s:sequence>
>>           <s:element minOccurs="0" maxOccurs="unbounded" 
>>     
> name="InfoString" 
>   
>> nillable="true">
>>             <s:complexType name="InfoString">
>>              <s:sequence>
>>                <s:element minOccurs="0" maxOccurs="1" 
>>     
> name="CodInfoString" 
>   
>> type="s:string" />
>>              </s:sequence>
>>             </s:complexType>
>>           </s:element>
>>         </s:sequence>
>>       </s:complexType>
>>
>> And I see no reason why any number of optional elements would not work. 
>> All optional element processing does a peek(), so peek will return NULL 
>> string no matter the number of optional elements.
>>
>>
>> Nadir K. Amra
>>
>> Franz Fehringer <feh@isogmbh.de> wrote on 01/15/2007 04:49:51 AM:
>>
>>
>> Hallo Nadir,
>>
>> Does the checked in fix correctly handle the case
>> <mytag mykey="myvalue"/>
>> where *two* (or more) optional elements are missing.
>> I was slightly concerned about this case(s) with my solution.
>>
>> Cheers
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>
>>
>>
>> [attachment "feh.vcf" deleted by Nadir Amra/Rochester/IBM] 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>     
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>   


Mime
View raw message