axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Samisa Abeysinghe <samisa.abeysin...@gmail.com>
Subject Re: wrong order of parameters in axis c++ 1.5 (using google API)
Date Mon, 25 Apr 2005 05:25:01 GMT
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 <classeng@clagi.de> 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
> 
>

Mime
View raw message