axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Senaka Fernando (JIRA)" <j...@apache.org>
Subject [jira] Updated: (AXIS2C-854) Error in SOAP Action Based Dispatching
Date Mon, 24 Dec 2007 15:36:43 GMT

     [ https://issues.apache.org/jira/browse/AXIS2C-854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Senaka Fernando updated AXIS2C-854:
-----------------------------------

    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

  was:
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.

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


> 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: code generation, 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
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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org


Mime
View raw message