DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12927>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12927 WSIFOperation_ApacheAxis fails to set SOAPaction on its Call object Summary: WSIFOperation_ApacheAxis fails to set SOAPaction on its Call object Product: Axis Version: 1.0-rc1 Platform: PC OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Basic Architecture AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I access the same webservice (the getSummary operation of http://live.capescience.com/wsdl/AirportWeather.wsdl ) using the WSIFDynamicProvider for Apache SOAP provider and the WSIFDynamicProvider for Apache Axis, with code based on the WSIF clients.DynamicInvoker sample (modified to take complex parameters and return parts). The ApacheSOAP provider generates an HTTP header for SOAPAction: SOAPAction: "capeconnect:AirportWeather:Station#getSummary"\r\n while the Axis provider generates SOAPAction: ""\r\n A perusal of the source code indicates that WSIFOperation_ApacheSOAP.invokeRequestResponseOperation() passes its soap action uri to Call.invoke as an argument. The analogous place for the Axis version is WSIFOperation_ApacheAxis.invokeRequestResponseOperation(), which fails to do anything with the soap action uri (which is correctly stashed on the operation object). In a normal Axis client, Service.createCall(portname, operationname) invokes Call.setOperation() which handles the establishment of the soap action uri in the Call object. The service in question rejects the request when an empty SOAPAction is supplied. Presumably others behave this way also. My version of wsif-1.2 dates from 9/4/2002.
