This is a known bug and I have looked to fix this before 1.5 release -but gave up due to the complexity of the fix required.
Basically the WSDL2Ws tool seem to have some assupmtions on the ordering of the elements and due to the current nature of implementation of the deserializer, it seems to be very hard to fix. I am currently busy with some WSDL construct support - once I am done with that I want to have a look into this. However, I am not sure how I could come up with a fix here - when I tried earlier, I ended up breaking array deserailization and I gave up Thanks, Samisa... On 4/23/05, Guido Classen <[EMAIL PROTECTED]> wrote: > Hello, > > it seams this topic was allread discused here, but it looks like a bug > and therefore I want ask again. > I've tried axis c++ 1.5. For testing purpose I've used the google > SOAP API (http://www.google.com/apis/). > While using WSDL2Ws it seams that the argument elements are in the wrong > order in the generated c++ source: > > E:\devel\soap\google_test>java org.apache.axis.wsdl.wsdl2ws.WSDL2Ws -oc-lc++ > -sclient GoogleSearch.wsdl 22.04.2005 18:00:35 > org.apache.axis.utils.JavaUtils isAttachmentSupported > WARNUNG: Unable to find required classes (javax.activation.DataHandler > and javax.mail.internet.MimeMultipart). Attachment support is disabled. > > Code generation completed. > > The following argument sequence of GoogleSearch.wsds > > ... > <message name="doGoogleSearch"> > <part name="key" type="xsd:string"/> > <part name="q" type="xsd:string"/> > <part name="start" type="xsd:int"/> > <part name="maxResults" type="xsd:int"/> > <part name="filter" type="xsd:boolean"/> > <part name="restrict" type="xsd:string"/> > <part name="safeSearch" type="xsd:boolean"/> > <part name="lr" type="xsd:string"/> > <part name="ie" type="xsd:string"/> > <part name="oe" type="xsd:string"/> > </message> > ... > > leads to this code fragment in GoogleSearchPort.cpp > > ... > m_pCall->setOperation("doGoogleSearch", "urn:GoogleSearch"); > applyUserPreferences(); > m_pCall->addParameter((void*)&Value0, "filter", XSD_BOOLEAN); > m_pCall->addParameter((void*)Value1, "key", XSD_STRING); > m_pCall->addParameter((void*)Value2, "restrict", XSD_STRING); > m_pCall->addParameter((void*)&Value3, "start", XSD_INT); > m_pCall->addParameter((void*)Value4, "ie", XSD_STRING); > m_pCall->addParameter((void*)&Value5, "safeSearch", XSD_BOOLEAN); > m_pCall->addParameter((void*)Value6, "lr", XSD_STRING); > m_pCall->addParameter((void*)&Value7, "maxResults", XSD_INT); > m_pCall->addParameter((void*)Value8, "oe", XSD_STRING); > m_pCall->addParameter((void*)Value9, "q", XSD_STRING); > ... > > The elements are in the wrong order, which lead to the same wrong order > on the SOAP wire > protocol. > Google comments this call with the error "no signature match" > Manually reodering the arguments in the captured wire protocol causes > google to give the > expected answer! > > any comments? > > Greetings > Guido Classen > >
