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
