You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-user@axis.apache.org by Nicholas Hart <nh...@real.com> on 2007/01/24 22:50:33 UTC
order of returned elements
I have a question regarding how AxisCPP parses a response. It's my
understanding that the order of the elements shouldn't matter, eg:
<myobj>
<foo>hello</foo>
<bar>world</bar>
</myobj>
should be equivalent to:
<myobj>
<bar>world</bar>
<foo>hello</foo>
</myobj>
however, in the stub client code generated by AxisCPP, the order
definitely matters. if the order elements are returned doesn't match up
to the order in which the stub tries to parse them, an error is set and
the rest of the object fails to parse.
I've been manually changing a bunch of my stub code to parse the order
returned by our server. however, this is a big pain and I fear that if
the order changes it will break my client.
Is this a known issue with AxisCPP? It seems like this could be fixed
by generating stubs that iterating through the elements in the response,
peek at their names and then invoke the appropriate parsing code for
each element. Or perhaps this should go into AxisCPP so that
getElement() doesn't look for the next element, but instead finds the
named element.
thoughts? comments?
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org
Re: order of returned elements
Posted by Franz Fehringer <fe...@isogmbh.de>.
Only if xsd:all is in effect (but note that i am not a real XSD expert).
Franz
Nicholas Hart schrieb:
>
> I have a question regarding how AxisCPP parses a response. It's my
> understanding that the order of the elements shouldn't matter, eg:
>
> <myobj>
> <foo>hello</foo>
> <bar>world</bar>
> </myobj>
>
> should be equivalent to:
>
> <myobj>
> <bar>world</bar>
> <foo>hello</foo>
> </myobj>
>
> however, in the stub client code generated by AxisCPP, the order
> definitely matters. if the order elements are returned doesn't match
> up to the order in which the stub tries to parse them, an error is set
> and the rest of the object fails to parse.
>
> I've been manually changing a bunch of my stub code to parse the order
> returned by our server. however, this is a big pain and I fear that
> if the order changes it will break my client.
>
> Is this a known issue with AxisCPP? It seems like this could be fixed
> by generating stubs that iterating through the elements in the
> response, peek at their names and then invoke the appropriate parsing
> code for each element. Or perhaps this should go into AxisCPP so that
> getElement() doesn't look for the next element, but instead finds the
> named element.
>
> thoughts? comments?
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-user-help@ws.apache.org
>
>
Re: order of returned elements
Posted by Nadir Amra <am...@us.ibm.com>.
Nicholas,
Yes, there is a JIRA: AXISCPP-987.
I will be looking at it soon. In addition, I have fixed the problem with
XSD types, but I am in the midst of some major overhaul - rewriting the
parser to eliminate duplication and ensure it reports errors and removing
lots of duplicate and redundant stuff in in deserializer. I have
completed this work and am now just ensuring that the test bucket competes
OK.
Nadir K. Amra
Nicholas Hart <nh...@real.com> wrote on 01/24/2007 03:50:33 PM:
>
> I have a question regarding how AxisCPP parses a response. It's my
> understanding that the order of the elements shouldn't matter, eg:
>
> <myobj>
> <foo>hello</foo>
> <bar>world</bar>
> </myobj>
>
> should be equivalent to:
>
> <myobj>
> <bar>world</bar>
> <foo>hello</foo>
> </myobj>
>
> however, in the stub client code generated by AxisCPP, the order
> definitely matters. if the order elements are returned doesn't match up
> to the order in which the stub tries to parse them, an error is set and
> the rest of the object fails to parse.
>
> I've been manually changing a bunch of my stub code to parse the order
> returned by our server. however, this is a big pain and I fear that if
> the order changes it will break my client.
>
> Is this a known issue with AxisCPP? It seems like this could be fixed
> by generating stubs that iterating through the elements in the response,
> peek at their names and then invoke the appropriate parsing code for
> each element. Or perhaps this should go into AxisCPP so that
> getElement() doesn't look for the next element, but instead finds the
> named element.
>
> thoughts? comments?
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org