I guess this a a bug in the code generator, could you please create a JIRA and attach your WSDL ?
Deepal > Any suggestions? We are still unable to get the AXIS clients to connect > after the CXF 1.5.5 upgrade on the server. > > No problems with SoapUI, .Net or CXF clients. If this needs to be reported > more officially, where can I do that? > > Many thanks. > > Wayne > > On 1/14/13 6:54 AM, "Wayne Holmes" <whol...@cequint.com> wrote: > >> >> On 1/11/13 9:50 PM, "Sagara Gunathunga" <sagara.gunathu...@gmail.com> >> wrote: >> >>> On Fri, Jan 11, 2013 at 1:05 AM, Wayne Holmes <whol...@cequint.com> >>> wrote: >>>> We are doing some interoperability testing, and after upgrading our >>>> server to CXF 1.5.5 we are seeing an exception thrown when we send a >>>> request from a AXIS 2 client with text: >>>> "The given SOAPAction >>>> http://text2idml.idml.server.cequint.com/Text2IDMLWebServiceImpl/queryHa >>>> n >>>> dsets does not match an operation." >>>> >>>> Did a line level trace, and the indeed see that SOAPAction is being set >>>> to >>>> "http://text2idml.idml.server.cequint.com/Text2IDMLWebServiceImpl/queryH >>>> a >>>> ndsets", even thought the WSDL for that operation specified no action: >>>> <wsdl:operation name="queryHandsets"> >>>> <soap:operation soapAction="" style="document" >>>> /> >>>> <wsdl:input name="queryHandsets"> >>>> <soap:body use="literal" /> >>>> </wsdl:input> >>>> <wsdl:output name="queryHandsetsResponse"> >>>> <soap:body use="literal" /> >>>> </wsdl:output> >>>> </wsdl:operation> >>>> >>>> Based on the comments in the security fix in CXF 1.5.5, it sounds to us >>>> like CXF is expecting the SOAPAction to be "" since that is what is in >>>> the CXF generated WSDL. (See http://cxf.apache.org/cve-2012-3451.html) >>>> >>>> I looked at the client generated by WSDL2JAVA (Axis2 version 1.6.2) and >>>> found this line: >>>> >>>> _operationClient.getOptions().setAction("http://text2idml.idml.server.ce >>>> q >>>> uint.com/Text2IDMLWebServiceImpl/queryHandsets"); >>>> >>>> Tried using the same server WSDL to client .Net and SOAPUI clients, and >>>> both of them are setting SOAPAction to "", so we are thinking there is >>>> an issue with AXIS2 talking to CXF 1.5.5 when the operation >>>> soapAction="" in the WSDL. >>>> >>>> So my questions are: >>>> - Is there a way to override the SOAPAction when the stubs are >>>> generated? >>> Try stub._getServiceClient().getOptions().setAction(...) >>> >>> >>> http://axis.apache.org/axis2/java/core/api/org/apache/axis2/client/Option >>> s >>> .html#setAction%28java.lang.String%29 >>> >>> Thanks ! >> We tried that, and what happens is the generated stub files end up >> overriding the SOAPAction when >> >> _operationClient.getOptions().setAction("http://text2idml.idml.server.cequ >> i >> nt.com/Text2IDMLWebServiceImpl/queryHandsets") is called in the generated >> stubs. >> >> We then altered the generated stub to: >> _operationClient.getOptions().setAction(""); >> And the SOAPAction is then changed to "urn:queryHandsets" by what appears >> to be some WSA code. (Based on a DEBUG level trace.) >> >> Generated clients using SoapUP, CXF and .Net to see what they do. In all >> cases the SOAPAction is set to "", which matches the WSDL. For some reason >> the AXIS code is insisting on changing the SOAPAction from what is in the >> WSDL. (That is, it is treating a SOAPAction of length zero as a missing >> value.) >> >>>> - If not, any samples for how to override the SOAPAction at runtime >>>> when using WSDL2JAVA generated stubs? >>>> >>>> Thanks in advance. >>>> >>>> Wayne Holmes >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: java-user-unsubscr...@axis.apache.org >>>> For additional commands, e-mail: java-user-h...@axis.apache.org >>>> >>> >>> >>> -- >>> Sagara Gunathunga >>> >>> Blog - http://ssagara.blogspot.com >>> Web - http://people.apache.org/~sagara/ >>> LinkedIn - http://www.linkedin.com/in/ssagara >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: java-user-unsubscr...@axis.apache.org >>> For additional commands, e-mail: java-user-h...@axis.apache.org >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-user-unsubscr...@axis.apache.org > For additional commands, e-mail: java-user-h...@axis.apache.org > > -- Blog - http://blogs.deepal.org/ --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@axis.apache.org For additional commands, e-mail: java-user-h...@axis.apache.org
