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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
