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/queryHandsets 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/queryHandsets", 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.cequint.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? - 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