You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by "nadir amra (JIRA)" <ax...@ws.apache.org> on 2006/08/12 03:16:13 UTC
[jira] Created: (AXISCPP-991) Deserializing complex type broken
when start-end element tag is encountered
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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: [jira] Commented: (AXISCPP-991) Deserializing complex type broken
when start-end element tag is encountered
Posted by Franz Fehringer <fe...@isogmbh.de>.
After short reflection i think my solution does not work in case several
optional subelements are missing.
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.
>>>
>>
>>
>
Re: [jira] Commented: (AXISCPP-991) Deserializing complex type broken when
start-end element tag is encountered
Posted by Nadir Amra <am...@us.ibm.com>.
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 <fe...@isogmbh.de> 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: 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
Re: [jira] Commented: (AXISCPP-991) Deserializing complex type broken
when start-end element tag is encountered
Posted by Franz Fehringer <fe...@isogmbh.de>.
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.
>>>
>>
>>
>
Re: [jira] Commented: (AXISCPP-991) Deserializing complex type broken
when start-end element tag is encountered
Posted by Franz Fehringer <fe...@isogmbh.de>.
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.
>>
>
>
[jira] Commented: (AXISCPP-991) Deserializing complex type broken
when start-end element tag is encountered
Posted by "nadir amra (JIRA)" <ax...@ws.apache.org>.
[ 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.
--
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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: [jira] Closed: (AXISCPP-991) Deserializing complex type broken
when start-end element tag is encountered
Posted by Franz Fehringer <fe...@isogmbh.de>.
OK thanks
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 <fe...@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
>
>
Re: [jira] Closed: (AXISCPP-991) Deserializing complex type broken
when start-end element tag is encountered
Posted by Franz Fehringer <fe...@isogmbh.de>.
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 <fe...@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 <fe...@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
>
>
Re: [jira] Closed: (AXISCPP-991) Deserializing complex type broken when
start-end element tag is encountered
Posted by Nadir Amra <am...@us.ibm.com>.
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 <fe...@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 <fe...@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
Re: [jira] Closed: (AXISCPP-991) Deserializing complex type broken
when start-end element tag is encountered
Posted by Franz Fehringer <fe...@isogmbh.de>.
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 <fe...@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
>
>
>
Re: [jira] Closed: (AXISCPP-991) Deserializing complex type broken when
start-end element tag is encountered
Posted by Nadir Amra <am...@us.ibm.com>.
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 <fe...@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
Re: [jira] Closed: (AXISCPP-991) Deserializing complex type broken
when start-end element tag is encountered
Posted by Franz Fehringer <fe...@isogmbh.de>.
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
Franz
nadir amra (JIRA) schrieb:
> [ https://issues.apache.org/jira/browse/AXISCPP-991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> nadir amra closed AXISCPP-991.
> ------------------------------
>
> Resolution: Fixed
> Fix Version/s: current (nightly)
>
> I moved the fault comment ot axiscpp-1011 (I reopened issue and pasted the comment), will be fixing it soon.
>
> I want to close out this issue. I created two testcases, StartEndElementAttributes and StartEndElement, one with attributes and one without, that return start/end element.
>
> The tests work and the code has been put to SVN. I implemented Franz's solution in keeping track when a start/end element was encountered, and a subsequent peek will return a null string when last node processed was a start/end element.
>
> The flag is set true or false when next() or anyNext() is invoked. Peek will check the flag and if start/end element, will return null string.
>
> Seems to work pretty good.
>
>
>> Deserializing complex type broken when start-end element tag is encountered
>> ---------------------------------------------------------------------------
>>
>> Key: AXISCPP-991
>> URL: https://issues.apache.org/jira/browse/AXISCPP-991
>> Project: Axis-C++
>> Issue Type: Bug
>> Components: Client - Deserialization
>> Reporter: nadir amra
>> Assigned To: nadir amra
>> Fix For: current (nightly)
>>
>>
>> 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.
>>
>
>
[jira] Closed: (AXISCPP-991) Deserializing complex type broken when
start-end element tag is encountered
Posted by "nadir amra (JIRA)" <ax...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/AXISCPP-991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
nadir amra closed AXISCPP-991.
------------------------------
Resolution: Fixed
Fix Version/s: current (nightly)
I moved the fault comment ot axiscpp-1011 (I reopened issue and pasted the comment), will be fixing it soon.
I want to close out this issue. I created two testcases, StartEndElementAttributes and StartEndElement, one with attributes and one without, that return start/end element.
The tests work and the code has been put to SVN. I implemented Franz's solution in keeping track when a start/end element was encountered, and a subsequent peek will return a null string when last node processed was a start/end element.
The flag is set true or false when next() or anyNext() is invoked. Peek will check the flag and if start/end element, will return null string.
Seems to work pretty good.
> Deserializing complex type broken when start-end element tag is encountered
> ---------------------------------------------------------------------------
>
> Key: AXISCPP-991
> URL: https://issues.apache.org/jira/browse/AXISCPP-991
> Project: Axis-C++
> Issue Type: Bug
> Components: Client - Deserialization
> Reporter: nadir amra
> Assigned To: nadir amra
> Fix For: current (nightly)
>
>
> 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: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Commented: (AXISCPP-991) Deserializing complex type broken
when start-end element tag is encountered
Posted by "Scott Exton (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-991?page=comments#action_12443453 ]
Scott Exton commented on AXISCPP-991:
-------------------------------------
I am not sure if you have a solution to this problem yet, but I also encountered the same problem today. I have managed to 'hack' a solution that works.
The problem comes down to the fact that if an item is correctly de-serialized an assumption is made that the next node is the terminator for the item (i.e. </item>). In our case the de-serialization was working correctly (it de-serialized an empty node), but the next node was not the terminator node, instead it was our next element. So, instead of skipping the terminator we skipped the next element.
So, to overcome the problem you need to add a check prior to the m_pParser->next() call to determine if the next element is a 'terminator' or not. You should then only move to the next node if the next node is a 'terminator'. We determine whether the next node is a terminator by peeking at the next node. If an empty string is returned we know that the next node is a terminator. This is not the most elegent solution but works for the time being.
Anyway, here is a code snippet for a new function within SoapDeSerializer.cpp. You need to change the lines within SoapDeSerializer.cpp which look like the following "m_pParser->next (); /* skip end node too */" with a call to the new skipEndNode function.
void SoapDeSerializer::skipEndNode()
{
/*
* According to the XMLParserXerces.cpp file (specifically the ::peek
* method), an empty string will be returned if the next element is
* a closing (or end) element. So, if the peek function does not return
* an empty string we do not want to advance to the next element.
*/
const char* nextName = m_pParser->peek();
if (nextName[0] == 0x00) {
m_pParser->next (); /* skip end node too */
}
}
Hope that this helps. Someone really needs to code up the optimal solution for this problem and add it back into the project. My lack of knowledge about the rest of Axis prevents me from being confident about doing this myself.
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Commented: (AXISCPP-991) Deserializing complex type broken
when start-end element tag is encountered
Posted by "Franz Fehringer (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-991?page=comments#action_12459322 ]
Franz Fehringer commented on AXISCPP-991:
-----------------------------------------
I think my current solution only works, if at most one optional subelement is missing.
The case of multiple optional/missing subelements could perhaps be settled by omitting the resetting of m_bStartEndElement at the beginning of peek() and relying on the unconditional reset when entering next() for the (END_ELEMENT,START_END_ELEMENT) node.
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Updated: (AXISCPP-991) Deserializing complex type broken
when start-end element tag is encountered
Posted by "nadir amra (JIRA)" <ax...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/AXISCPP-991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
nadir amra updated AXISCPP-991:
-------------------------------
Comment: was deleted
> Deserializing complex type broken when start-end element tag is encountered
> ---------------------------------------------------------------------------
>
> Key: AXISCPP-991
> URL: https://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: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Commented: (AXISCPP-991) Deserializing complex type broken
when start-end element tag is encountered
Posted by "Franz Fehringer (JIRA)" <ax...@ws.apache.org>.
[ 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Commented: (AXISCPP-991) Deserializing complex type broken
when start-end element tag is encountered
Posted by "Franz Fehringer (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-991?page=comments#action_12459324 ]
Franz Fehringer commented on AXISCPP-991:
-----------------------------------------
For a correct parse of SoapFaults and their details i had to make two additional small changes (apart from making faultactor optional, see AXISCPP-1011):
$ pwd
/cd/d/Quellen/SVN/axis/c/src/soap
Index: SoapDeSerializer.cpp
===================================================================
--- SoapDeSerializer.cpp (Revision 480584)
+++ SoapDeSerializer.cpp (Arbeitskopie)
@@ -899,7 +904,7 @@
// Skip the faultdetail tag
if (!m_pNode)
- m_pParser->next ();
+ m_pNode = m_pParser->next();
m_nStatus = AXIS_SUCCESS;
@@ -1619,7 +1624,8 @@
if (bReturn)
{
m_pNode = m_pParser->next (); /* skip end element node too */
- m_pNode = NULL; /* AXISCPP-978 node identified and used */
+ if (m_pNode->m_type != START_ELEMENT || m_pNode->m_type2 != END_ELEMENT)
+ m_pNode = NULL; /* AXISCPP-978 node identified and used */
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.
--
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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org