axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Deepal Jayasinghe (JIRA)" <>
Subject [jira] Resolved: (AXIS2-2798) Soap action string mismatch does not prevent web service method from running.
Date Wed, 04 Jul 2007 09:21:04 GMT


Deepal Jayasinghe resolved AXIS2-2798.

    Resolution: Fixed

You can solve the issue by adding action mapping element into services.xml as I mentioned
in following article.

> Soap action string mismatch does not prevent web service method from running.
> -----------------------------------------------------------------------------
>                 Key: AXIS2-2798
>                 URL:
>             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:
> However the new receiving service expects a different SOAP action:
> 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
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:
For additional commands, e-mail:

View raw message