Hi Senaka, Do you have an example of what the services.xml file looks like to do the wildcarding?
I guess the action is where you specify the wildcard (e.g. "Update*Item" to map to "UpdateItem)? Thanks, -Dave. -----Original Message----- From: Senaka Fernando [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 11, 2008 3:18 PM To: axis-c-dev@ws.apache.org Subject: RE: [jira] Commented: (AXIS2C-854) Error in SOAP Action Based Dispatching Hi again Dave, It is working. You will have to set the action (SOAP or WS-Addressing) to get this thing to work. Regards, Senaka > 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.j >> ira >> .plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577 >> 239 >> #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] > > --------------------------------------------------------------------- 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]
