axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Sebastien Delfino <>
Subject Plugging in a custom dispatcher, was Re: How to dispatch to a REST service
Date Sat, 16 Sep 2006 16:09:31 GMT
Samisa Abeysinghe wrote:
> Jean-Sebastien Delfino wrote:
>> Hi,
>> I'm using the REST support in Axis2C 0.93 to invoke SCA services in 
>> Apache Tuscany, and it has been working pretty well so far. I now 
>> would like to customize a little how requests get dispatched to a 
>> particular service.
>> I am currently using the following URL: 
>> http://localhost:9090/axis2/services/customer?id=1234 to invoke my 
>> customer info Web service and pass to it customer id 1234, so far so 
>> good.
>> Now I would like to change this a little and invoke the customer info 
>> service using a slightly different URL: 
>> http://localhost:9090/axis2/services/customer/1234. Customer id 1234 
>> is now specified as part of the path instead of a parameter. I still 
>> need a single service for all customers, and the ability to get the 
>> customer id in the Axis2 service skeleton.
>> Is this possible? 
> This is not possible as of now, as we are dependent on the '?' 
> separation for parameters.
>> What do I need to put in my services.xml to enable this? and how will 
>> I get the part of the URL after customer/ in my Axis2 service skeleton?
> Unfortunately we have not implemented a mechanism for this. In theory, 
> you should be able to write your own dispatcher to get this done. e.g. 
> see modules/core/engine/req_uri_disp.c. You write a custom dispatcher 
> and include that extended dispatcher in "<phaseOrder type="inflow">" 
> section's 'Dispatch' phase in axis2.xml. However we have not tested 
> plugging in dispatchers.
> Alternatively, you can extend the logic in axis2_req_uri_disp_find_op 
> method of modules/core/engine/req_uri_disp.c. and get the rest of the 
> string after customer/ in the URI and set this as a property in the 
> message context. Then, in the service skeleton, you can pull this 
> property from the message context. I think this approach is simpler 
> than to try and write a custom dispatcher.
> Thanks,
> Samisa...
>> Thanks...
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Thanks for the info. I am now able to plug in a custom dispatcher. I 
prefer this approach as I want Tuscany to work with a plain Axis2C 
distribution without having to customize its source.

I had to add the following to my axis2.xml:
        <dispatcher class="tuscany_sca_ws_dispatcher"/>

Adding to the <phaseOrder type="inflow"> section didn't seem to trigger 
the loading of my dispatcher.

I also had to make two minor code changes in Axis2C:
 >         if(disp_node)
 >         {
 >             disp_element = AXIOM_NODE_GET_DATA_ELEMENT(disp_node,
 >                 env);
 >         }
 >         if(!disp_element)
 >         {
 >             qname_itr_has_next = 
 >                 env);
 >             continue;
 >         }

This fixes a memory violation with disp_element not being initialized.

and in axis2c-src-0.93/modules/core/description/handler_desc.c
<     if 
(AXIS2_PARAM_CONTAINER_IS_PARAM_LOCKED(handler_desc_impl->parent, env,
<         AXIS2_PARAM_GET_NAME(param, env)) )
 >     if (handler_desc_impl->parent)
<             AXIS2_FAILURE);
<         return AXIS2_FAILURE;
 >         if 
(AXIS2_PARAM_CONTAINER_IS_PARAM_LOCKED(handler_desc_impl->parent, env,
 >             AXIS2_PARAM_GET_NAME(param, env)) )
 >         {
 >                 AXIS2_FAILURE);
 >             return AXIS2_FAILURE;
 >         }

Ths is to avoid a memory violation because the parent of my custom 
dispatcher's handler_desc is NULL. I am not sure how to set it, or if 
the Axis2C runtime should set the parent after the handler is loaded.

I hope this makes sense as I've been guessing what to do by stepping 
into the code in the debugger... But I am able to get my dispatcher 
invoked at least when the other dispatchers play along and execute 

Now my next question is: How can I control the order of execution of the 
dispatchers? Currently the engine's req_uri_disp dispatcher always seems 
to be invoked first and fails if it doesn't find the target service in 
the service configuration, so my dispatcher doesn't get a chance to be 
called. This pretty much defeats the purpose as my dispatcher is 
supposed to contribute new dispatching logic :) unless I'm missing 



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

View raw message