You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "David Illsley (JIRA)" <ji...@apache.org> on 2007/01/12 10:08:27 UTC
[jira] Resolved: (AXIS2-1969) SOAPAction based routing does not
route correctly based on wsdl:binding/wsdl:operation/soap:operation
soapAction
[ 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.
> at org.apache.axis2.addressing.AddressingFaultsHelper.triggerAddressingFault(AddressingFaultsHelper.java:156)
> at org.apache.axis2.addressing.AddressingFaultsHelper.triggerActionNotSupportedFault(AddressingFaultsHelper.java:131)
> at org.apache.axis2.handlers.addressing.AddressingWSDLValidationHandler.checkAction(AddressingWSDLValidationHandler.java:113)
> at org.apache.axis2.handlers.addressing.AddressingWSDLValidationHandler.invoke(AddressingWSDLValidationHandler.java:39)
> at org.apache.axis2.engine.Phase.invoke(Phase.java:382)
> at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:247)
> at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:164)
> at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:337)
--
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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org