axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Barrett (JIRA)" <>
Subject [jira] Resolved: (AXIS2-2178) The wrong AxisOperation could be resolved to if SOAPAction is not unique across the AxisService
Date Thu, 15 Feb 2007 16:45:05 GMT


Jeff Barrett resolved AXIS2-2178.

    Resolution: Fixed

Changes made as described above plus a test to verify the behavior using SOAPActionBasedDispather.
 Committed revision 507996.

> The wrong AxisOperation could be resolved to if SOAPAction is not unique across the AxisService
> -----------------------------------------------------------------------------------------------
>                 Key: AXIS2-2178
>                 URL:
>             Project: Axis 2.0 (Axis2)
>          Issue Type: Bug
>            Reporter: Jeff Barrett
>         Assigned To: Jeff Barrett
> When a SOAPAction is added to an AxisService for an operation, it is put into a HashMap
of various aliases for operations under that service.  If that SOAPAction already existed
in the hashmap, the new mapping simply overwrites the old mapping.
> That may cause an incoming message to be rounted to the wrong operation.  For example,
if my WSDL has operations A() and B() , both of which have the SOAPAction "myAction", the
last operation added to the alias map is the one that will receive all requests with a SOAPAction
of "myAction".
> I believe the appropriate fix is as follows:
> 1) Before adding to the alias map, check if that alias already exists in the aliasMap
or in the invalid aliases map (see 3c)
> 2) If so, and the operations match, then simply return.
> 3) If the operations do not match
> 3a) Do not add this operation
> 3b) Remove the operation that is already in the alias map
> 3c) Add this alias to a list of invalid aliases
> 3d) And do not add this alias to the aliasMap. 
> The effect of this change is that IF a SOAPAction maps to more than one operation under
a service, that SOAPAction will not be used to route incoming messages, since there is no
way to determine WHICH operation the message is actually destined for based on the SOAPAction.

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