axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dimuthu Gamage (JIRA)" <>
Subject [jira] Updated: (AXIS2C-854) Error in SOAP Action Based Dispatching
Date Wed, 26 Dec 2007 05:11:43 GMT


Dimuthu Gamage updated AXIS2C-854:

    Component/s:     (was: code generation)

This is not relevant with code-generation component. Since the patch does not ask to update
any generating code.

> Error in SOAP Action Based Dispatching
> --------------------------------------
>                 Key: AXIS2C-854
>                 URL:
>             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
>         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
> 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]
> [2]

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