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 "Deepal Jayasinghe (JIRA)" <ji...@apache.org> on 2007/06/13 01:06:26 UTC
[jira] Assigned: (AXIS2-2798) Soap action string mismatch does not
prevent web service method from running.
[ https://issues.apache.org/jira/browse/AXIS2-2798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Deepal Jayasinghe reassigned AXIS2-2798:
----------------------------------------
Assignee: Deepal Jayasinghe
> 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
> Fix For: 1.2
>
>
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org