[
https://issues.apache.org/jira/browse/AXIS2C-854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Senaka Fernando resolved AXIS2C-854.
------------------------------------
Resolution: Fixed
Fix Version/s: Current (Nightly)
Fixed Issue
> Error in SOAP Action Based Dispatching
> --------------------------------------
>
> Key: AXIS2C-854
> URL: https://issues.apache.org/jira/browse/AXIS2C-854
> Project: Axis2-C
> Issue Type: Bug
> Components: core/addressing, core/context, core/deployment,
> core/description, core/engine, core/phaseresolver
> Affects Versions: 1.2.0
> Reporter: Senaka Fernando
> Priority: Critical
> Fix For: Current (Nightly)
>
> Attachments: diff.txt, diff2.txt
>
>
> 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
--
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]
