[
https://issues.apache.org/jira/browse/AXIS2-2798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12507418
]
Davanum Srinivas commented on AXIS2-2798:
-----------------------------------------
David,
You can comment out SOAPMessageBodyBasedDispatcher from the axis2.xml
thanks,
dims
> Soap action string mismatch does not prevent web service method from running.
> -----------------------------------------------------------------------------
>
> Key: AXIS2-2798
> URL: https://issues.apache.org/jira/browse/AXIS2-2798
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Affects Versions: 1.2
> Environment: Windows XP Pro, Tomcat 5.0.28, Axis2 1.2
> Reporter: David R. Kraus
> Assignee: Deepal Jayasinghe
>
> I have an old client which sends the following SOAP action:
> http://company.com/webservices/GetInfo
> However the new receiving service expects a different SOAP action:
> http://company.com/webservices/v2/GetInfo
> The idea is that when a service becomes incompatible with previous clients,
> you change the namespace to prevent older clients from accessing. So, we
> added a version number to the webservice namespace, and to all SOAP actions,
> to control access.
> However, I discovered that the Axis2 (1.2) service actually accepted the
> GetInfo action/call and performed the operation, even though the version
> number was missing from the SOAP action string. When I traced through Axis2
> code I saw that the SOAP action mismatch was detected, but that the service
> code was able to match the operation name GetInfo by comparing the SOAP
> action suffix "GetInfo" to the operation GetInfo, and so proceeded with
> handling it.
> Anyway, is this a configurable behavior? Should this be happening?
> I did some tracing through Axis2 code and this is what I saw:
> 1. SOAPActionBasedDispatcher.findOperation can't find /GetInfo
> 2. AddressingBasedDispathcer.findOperation can't find /GetInfo
> 3. SOAPMessageBodyBasedDispatcher.findOperation is able to find GetInfo and
> processing continues successfully.
> Below is SOAPMessageBodyBasedDispatcher.findOperation. See comment added to
> source...
> public AxisOperation findOperation(AxisService service, MessageContext
> messageContext)
> throws AxisFault {
> OMElement bodyFirstChild =
> messageContext.getEnvelope().getBody().getFirstElement();
> AxisOperation axisOperation = null;
> if (bodyFirstChild != null){
> axisOperation =
> service.getOperationByMessageElementQName(bodyFirstChild.getQName());
> // this is required for services uses the RPC message receiver
> if (axisOperation == null){
> QName operationName = new QName(bodyFirstChild.getLocalName());
> axisOperation = service.getOperation(operationName);//****This
> is where the axisOperation is finally found successfully.****
> }
> }
> return axisOperation;
> }
> My interpretation of the behavior was that Axis2 was able to find the
> operation GetInfo, so it continued, even thought the initial soap action
> string was not matched. When I tried an example of a soap action where the
> soap action suffix did not match the operation name in the WSDL, then failure
> occurred as expected. So, if I had a soap action like
> http://company.com/webservices/GetData2 which was associated with an
> operation named GetData, then the soap action mismatch would occur as before,
> but SOAPMessageBodyBasedDispatcher.findOperation could not match GetData2
> with GetData, so the request failed.
> thanks, Dave
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
