axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Senaka Fernando" <>
Subject RE: [jira] Commented: (AXIS2C-854) Error in SOAP Action Based Dispatching
Date Tue, 11 Mar 2008 22:02:18 GMT
Hi Dave,

Yes, I was in fact referring to the same question you intended. Seems that
this was added [1]. But, it doesn't seem to work. Will take a good look to
see if something is altered or whether I missed out on something.



> Hi Senaka,
> Have you had a chance to look at my question below?
> Thanks,
> -Dave.
> -----Original Message-----
> From: Dave Meier (JIRA) []
> Sent: Monday, March 10, 2008 3:47 PM
> To:
> Subject: [jira] Commented: (AXIS2C-854) Error in SOAP Action Based
> Dispatching
>     [
> .plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577239
> #action_12577239 ]
> 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.
> [1]
> Regards,
> Senaka
>> 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
> "UpdateFoo"
>> 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 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]
>> [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:
> **********************************************************************
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> Any unauthorized review, use, disclosure or distribution is prohibited. If
> you are not the intended recipient, please contact the sender by reply
> e-mail and destroy all copies of the original message.
> **********************************************************************
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message