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.
[1] https://issues.apache.org/jira/browse/AXIS2C-954 Regards, Senaka > Hi Senaka, > > Have you had a chance to look at my question below? > > Thanks, > > -Dave. > > -----Original Message----- > From: Dave Meier (JIRA) [mailto:[EMAIL PROTECTED] > Sent: Monday, March 10, 2008 3:47 PM > To: axis-c-dev@ws.apache.org > Subject: [jira] Commented: (AXIS2C-854) Error in SOAP Action Based > Dispatching > > > [ > https://issues.apache.org/jira/browse/AXIS2C-854?page=com.atlassian.jira > .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 [mailto:[EMAIL PROTECTED] > 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] https://issues.apache.org/jira/browse/AXIS2C-854 > > 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: https://issues.apache.org/jira/browse/AXIS2C-854 >> 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] 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > ********************************************************************** > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
