axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Senaka Fernando (JIRA)" <>
Subject [jira] Created: (AXIS2C-854) Error is SOAP Action Based Dispatching
Date Mon, 24 Dec 2007 14:56:43 GMT
Error is SOAP Action Based Dispatching

                 Key: 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

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.

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, 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.

The proper 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.


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