[jira] Resolved: (AXIS2-1969) SOAPAction based routing does not route correctly based on wsdl:binding/wsdl:operation/soap:operation soapAction

[David Illsley (JIRA)]

     [ 
https://issues.apache.org/jira/browse/AXIS2-1969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Illsley resolved AXIS2-1969.
----------------------------------

    Resolution: Fixed

Put a simple fix to add calls to mapActionToOperation when soapAction is found 
in r495518
This fixes the soapAction dispatch problem I'd just run into. Jeff, can you 
confirm it fixes yours?

> SOAPAction based routing does not route correctly based on 
> wsdl:binding/wsdl:operation/soap:operation soapAction
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: AXIS2-1969
>                 URL: https://issues.apache.org/jira/browse/AXIS2-1969
>             Project: Apache Axis 2.0 (Axis2)
>          Issue Type: Bug
>            Reporter: Jeff Barrett
>         Assigned To: David Illsley
>
> The Axis2 engine is not correctly handling a SOAPAction wsdl extensibility 
> element (details below).  The only SOAPAction routing that will work is if 
> the SOAPAction is coincidently the same as the operation name.
> DETAILS
> =======
> The problem in in WSDL11ToAxisServiceBuilder.  The basic flow is
> populateService
>     processBinding
>         processPortType
>             populateOperations
>                 WSDL11ActionHelper for Input
>                 WSDL11ActionHelper for Output
>                 WSDL11ActionHalper for Fault
>                 return
>             AxisService addOperation
>                 // NOTE that at this point the SOAPAction has NOT been 
>                 // on the operation!  The SOAPAction is specified in the 
> wsdl:binding
>                 // and that has not been processed yet.  So, this returns 
> null or an empty string
>                 soapAction = axisOperation.getSoapAction
>                 if (soapAction not empty)
>                     // As noted above, this isn't called because soapAction 
> is empty
>                     mapActionToOperation(soapAction, operation)
>                         
>                 return
>         // NOW we get the wsdl bindings and process them, so this is the 
> point we will encounter the
>         // SOAP Action in the WSDL binding
>         for each operation in the binding
>             
> copyExtensibleElements(wsdl4jBindingOperation.getExtensibilityElements(), 
> dif, operation, BINDING_OPERATION);
>                 // At this point, for a wsdl4jElement instanceof 
> SOAP12Operation or wsdl4jElement instanceof SOAPOperation
>                 // we will set the SOAP action on the operation
>                 if(isTraceEnabled){
>                     log.trace("copyExtensibleElements:: setSoapAction 
> "+soapOperation.getSoapActionURI());
>                 }
>                 axisOperation.setSoapAction(soapOperation.getSoapActionURI());
>                 
> The problem with the above is that SOAP action from the WSDL binding is 
> never added to the AxisService.operationsAliasesMap which is done by 
> calling mapActionToOperation.
> Note that I've only looked at WSDL11ToAxisServiceBuilder, but I suspect 
> the same problem existsin WSDL20ToAxisServiceBuilder.
> The net effect of all the above is that SOAPActionBasedDispatcher will 
> only find an operation if the SOAPAction from the message happens to be 
> the same as the AxisOperation name. 
> So given the following WSDL snippet:
>   <wsdl:binding name="BGCKBinding" type="tns:BGCKIntf">
>     <soap:binding style="document" 
> transport="http://schemas.xmlsoap.org/soap/http"/>
>     <wsdl:operation name="submitBGCK">
>       <soap:operation soapAction="http://ibm.com/bgck/submitBGCK"/>
>       
> The operation "submitBGCK" would not be found given a SOAPAction of 
> "http://ibm.com/bgck/submitBGCK";.
> Note that even though soap:operation soapAction is never used correctly, an 
> error 
> does not always occur.  In some cases (wrapped), the correct operation (or 
> at least an operation) can be determined by the 
> SOAPMessageBodyBasedDispatcher.  However, this will only "work" if 
> WS-Addressing headers are not present.  If they are present, then WS-A 
> will throw an exception because the AxisOperation was not found: 
> org.apache.axis2.AxisFault: The [action] cannot be processed at the 
> receiver.&#13;
>       at 
> org.apache.axis2.addressing.AddressingFaultsHelper.triggerAddressingFault(AddressingFaultsHelper.java:156)&#13;
>       at 
> org.apache.axis2.addressing.AddressingFaultsHelper.triggerActionNotSupportedFault(AddressingFaultsHelper.java:131)&#13;
>       at 
> org.apache.axis2.handlers.addressing.AddressingWSDLValidationHandler.checkAction(AddressingWSDLValidationHandler.java:113)&#13;
>       at 
> org.apache.axis2.handlers.addressing.AddressingWSDLValidationHandler.invoke(AddressingWSDLValidationHandler.java:39)&#13;
>       at org.apache.axis2.engine.Phase.invoke(Phase.java:382)&#13;
>       at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:247)&#13;
>       at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:164)&#13;
>       at 
> org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:337)&#13;

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]