axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nadir Amra <a...@us.ibm.com>
Subject Re: [jira] Closed: (AXISCPP-991) Deserializing complex type broken when start-end element tag is encountered
Date Fri, 26 Jan 2007 01:42:35 GMT
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