would be nice to know the difference looking with a TCP Monitor! Josef
-----Ursprüngliche Nachricht----- Von: Deepal Jayasinghe [mailto:dee...@opensource.lk] Gesendet: Mittwoch, 30. Januar 2013 17:12 An: java-user@axis.apache.org Betreff: Re: SOAPAction value in AXIS generated stubs causing problems with server upgraded to CXF 1.5.5 from CXF 1.5.0 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/qu >>>> eryHa >>>> 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/q >>>> ueryH >>>> 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.serv >>>> er.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/O >>> ption >>> 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 --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@axis.apache.org For additional commands, e-mail: java-user-h...@axis.apache.org
