Srinath Perera wrote:
> Hi Ruwan;
>
> I am not sure about how we do the default operation.
>
Please see my comments in line;
> First, even though we use the operation name "mediate" as the default
> operation, AxisService will not have a corresponding operation, so a
> operation will not be set. So if we use a default operation, we should
> add a new AxisOperation object to the AxisService.
>
No..., if you create a proxy service without giving a WSDL, that
particular axis service object will have a operation called "mediate",
and this is where the default operation comes into play.
> Second, you are saying "Operation", parameter is required. Then we
> should add that to the sample as well.
>
"Operation" parameter is required only if you are creating a proxy by
specifying a WSDL, and the sample doesn't have a WSDL so the sample is
correct.
Thanks,
Ruwan
> Thanks
> Srinath
>
>
>
>>>> 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
>>
>>
>
>
>
>
--
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
