Ruwan Linton wrote:
> Srinath Perera wrote:
>> Hi All;
>>
>> Following code in the VFSTrasnportListener try to find the operation
>> from the services.xml, and use a default value when it is not found.
>> However, if the service do not have a operation whose name matches the
>> default value, a operation will not be set, and consequently, the
>> processing will fail at the post dispatch verifications. I guess one
>> can work around by adding a parameter called "Operation" in to the
>> services.xml, but IMO this is a bug.
>>
> This seems to be an issue, let me dig into this a bit more and get
> back to you.
Hi Srinath,
I had a look at this code and the logic associated with it. It seems to
be correct and here is the interpreted logic;
There are two possible ways of creating a proxy service (Here I am
limiting the VFS transport to proxy services) either by giving a WSDL or
without a one. In the case of a proxy service which is created by giving
a WSDL it has a set of operations described in the WSDL, where as in the
other case, you will only have one default operation which is assumed to
be "mediate" with the QName "urn:mediate".
So at the VFS dispatching, there has to be some means of letting the
transport know the operation to which this particular message has to be
dispatched to. This is because normal axis2 dispatching logic is not
going to work with the VFS transport and also it has to know the
operation for the post dispatch verification handlers to let the message
through according to the axis2 architecture.
So the only possible option if you have created a proxy with providing a
WSDL is to provide the expected operation as a service parameter. Bein
said that this parameter doesn't have to be in a service.xml, it can be
declared within the proxy service configuration as a parameter with the
name "Operation". (Basically synapse sets all its proxy service
parameters as axis service parameters into the axis2 service object).
With the above explanation the scenario that you have faced seems to be
a user error at the configuration level.
Thanks,
Ruwan
PS: I came across a dispatching issue in the VFS transport listener at
operation dispatching which leads to an NPE and fixed that.
>
> Thanks,
> Ruwan
>> Thanks
>> Srinath
>>
>> AxisService service = entry.getService();
>> if (service != null) {
>> msgContext.setAxisService(service);
>>
>> // find the operation for the message, or default to one
>> Parameter operationParam =
>> service.getParameter(BaseConstants.OPERATION_PARAM);
>> QName operationQName = (
>> operationParam != null ?
>>
>> BaseUtils.getQNameFromString(operationParam.getValue()) :
>> BaseConstants.DEFAULT_OPERATION);
>>
>> AxisOperation operation =
>> service.getOperation(operationQName);
>> if (operation != null) {
>> msgContext.setAxisOperation(operation);
>> }
>> }
>>
>>
>
>
--
Ruwan Linton
Senior Software Engineer & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: [email protected]; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com
_______________________________________________
Esb-java-user mailing list
[email protected]
https://wso2.org/cgi-bin/mailman/listinfo/esb-java-user
