axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dave Meier (JIRA)" <>
Subject [jira] Commented: (AXIS2C-854) Error in SOAP Action Based Dispatching
Date Mon, 10 Mar 2008 22:46:47 GMT


Dave Meier commented on AXIS2C-854:

Hi Senaka,

I just want to make sure we are talking about the same thing here.  This was with respect
to the question I asked about mapping an operation, where I have an existing operation "UpdateItem",
but I want to serve a soap request that has "UpdateFooItem" inside.  I want it to map to "UpdateItem"
when it calls my server code.  Can you show me an example of what the entry in services.xml
looks like for this scenario?

Here's the orginal email thread:

-----Original Message-----
From: Senaka Fernando []
Sent: Friday, January 25, 2008 11:17 PM
To: Apache AXIS C Developers List
Subject: RE: Axis2C support for dynamic operations

Hi Dave,

I did some modifications to the action-mapping and operation name resolution in the soap_action_based_dispatcher
on Axis2/C. The patch is currently being moderated by the developers. Once it has been done,
you may go ahead with providing any alias you desire for your operation. I will add onto this
the ability to accept the '*' character, for alias mapping scenarios. You may refer issue,
AXIS2C-854, at [1] for more information.

This will be made available during the next week.



> Hi Samisa,
> Is there any way to do the equivalent of "any" for a service?  Kind of

> like an "any" element in a schema, except for an operation.  All I 
> need is to have the engine call my invoke method and at that point I 
> can write all the code that knows how to handle the operation.
> If this is not possible, maybe I could alter the axis2 code where it 
> looks up the operation and map it to an existing operation, but store 
> the original operation name in the context.  So for example, if I have

> a known operation called "Update" and a request comes in called 
> "UpdateFoo" I would map this operation to "Update" and store
> somewhere in the context.  So I would have something like the 
> following in my services.xml:
> <operation name="Update" dynamic="Update*"> <parameter 
> name="wsamapping">\"\"</parameter>
> </operation>
> Then on the response, I would need to make sure it used the original 
> "UpdateFoo" name.
> I don't mind going off and modifying the axis2 code for my purposes to

> make this work.  Can you point me to where this would be done?
> Thanks,
> -Dave.

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