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/11/29 21:45:22 UTC
[jira] Commented: (AXISCPP-991) Deserializing complex type broken
when start-end element tag is encountered
[ 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] 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.
>>
>
>