Operation not set [sometimes] When using VFS

[Srinath Perera-3]

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.

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);
                }
            }

--
============================
Srinath Perera:
   Indiana University, Bloomington
   http://www.cs.indiana.edu/~hperera/
   http://srinathsview.blogspot.com/

_______________________________________________
Esb-java-user mailing list
Esb-java-user@...
https://wso2.org/cgi-bin/mailman/listinfo/esb-java-user

[Ruwan Linton-3]

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.

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: ruwan@...; cell: [phone]
blog: http://ruwansblog.blogspot.com 


_______________________________________________
Esb-java-user mailing list
Esb-java-user@...
https://wso2.org/cgi-bin/mailman/listinfo/esb-java-user

[Ruwan Linton-3]

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: ruwan@...; cell: [phone]
blog: http://ruwansblog.blogspot.com 


_______________________________________________
Esb-java-user mailing list
Esb-java-user@...
https://wso2.org/cgi-bin/mailman/listinfo/esb-java-user

[Ruwan Linton-3]

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: ruwan@...; cell: [phone]
>> blog: http://ruwansblog.blogspot.com
>>
>>    
>
>
>
>  

--
Ruwan Linton
Senior Software Engineer & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ruwan@...; cell: [phone]
blog: http://ruwansblog.blogspot.com 


_______________________________________________
Esb-java-user mailing list
Esb-java-user@...
https://wso2.org/cgi-bin/mailman/listinfo/esb-java-user

[Ruwan Linton-3]

Srinath Perera wrote:
> Hi Ruwan;
>
> I guess I see whats happening. Only thing is since sample is geared
> towards the none WSDL case, that might mislead the WSDL based case. I
> think best approach is to throw a error if "operation parameter is not
> found" AND "no operation called mediate" saying, this is a user
> configuration error and asking user to add a parameter called
> operation, which points to WSDL operation name.
>  
+1

Thanks,
Ruwan

> Thanks
> Srinath
>
>
>
> On Tue, Jun 9, 2009 at 10:15 AM, Ruwan Linton<ruwan@...> wrote:
>  
>> 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: ruwan@...; cell: [phone]
>>>> blog: http://ruwansblog.blogspot.com
>>>>
>>>>
>>>>        
>>>
>>>
>>>      
>> --
>> Ruwan Linton
>> Senior Software Engineer & Product Manager; WSO2 ESB; http://wso2.org/esb
>> WSO2 Inc.; http://wso2.org
>> email: ruwan@...; cell: [phone]
>> blog: http://ruwansblog.blogspot.com
>>
>>    
>
>
>
>  

--
Ruwan Linton
Senior Software Engineer & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ruwan@...; cell: [phone]
blog: http://ruwansblog.blogspot.com 


_______________________________________________
Esb-java-user mailing list
Esb-java-user@...
https://wso2.org/cgi-bin/mailman/listinfo/esb-java-user