Details
-
Bug
-
Status: Closed
-
Critical
-
Resolution: Fixed
-
1.2.0
-
None
-
None
Description
IN SOAP Action Based Dispatching, the Axis2/C engine is not capable of identifying operations corresponding to SOAP Actions that do not contain a URL with the operation name as a part of it. And, thus, violates the specification of WS-I where the SOAP action can be any valid uri.
The proposed fix in diff.txt enables the user to specify such uri's as an actionMapping element in the services.xml. This satisfies the usage of the particular element as in [1].
However, due to our implementation, the user can also specify such uri's as a wsamapping parameter. And, that parameter is available as a operation-to-action-mapping even when WS-Addressing is disabled and thus violating the use of the wsamapping parameter as in [2].
To overcome this issue, I have attached a second patch that allows the user only to use the actionMapping element if WS-Addressing is disabled, so that the SOAP Action Based Dispatcher can identify the particular operation. When WS-Addressing is enabled, the wsamapping parameter and the actionMapping element are both available for operation name resolution.
But for services that do not have WS-Addressing enabled in the service.xml but where WS-Addressing is engaged globally, the second patch (diff2.txt), has an awkward approach of setting action-mappings specified in wsamapping parameters when the phase resolver globally engages modules to services. This is due to our implementation having global module attachment after populating all the services.
A better approach would have been to initially identify globally enabled modules and attach them to each service during the population stage. Correct me if I'm wrong. However, this requires a great deal of re-working and I have not attempted that.
[1] http://wso2.org/library/2060
[2] http://wso2.org/library/2605
Attachments
Attachments
Issue Links
- incorporates
-
-
- Resolved
-