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<[email protected]> 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: [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 >> >> > > > > -- 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
