Hi, I think we will have to test call mediator in blocking mode for some different use cases. Then we will have to update Documentation about blocking capability of call mediator. For example the Call Mediator Documentation for ESB 4.9.0 [1] does not contain any information about blocking behavior of the call mediator. I think most of the people do not know about this feature because of that. In any case we will have to test blocking behavior more as there are some complains about it.
[1] https://docs.wso2.com/display/ESB490/Call+Mediator Thank you, On Thu, Dec 10, 2015 at 10:39 AM, Kathees Rajendram <kath...@wso2.com> wrote: > +1 to deprecate Callout mediator since we have the Callout mediator > functionalities in Call mediator. > > On Thu, Dec 10, 2015 at 1:18 AM, Vidura Gamini Abhaya <vid...@wso2.com> > wrote: > >> I've found DBReport / DBLookup to be quite useful for simple DB >> operations as they are easy to do OOTB. While DB Lookup mediator maybe >> limited in it's ability to only being able to return a single row of data, >> DB Report mediator is still quite useful in writing to a database, >> especially when we use a DB as part of the mediation sequences. >> >> I also feel it is worth continuing with POJOCommand, as it is the most >> simplest way of executing some custom code as part of a sequence. Although >> it is possible to do the same with a Class mediator, one doesn't have to >> worry about adding the proper jars, working with MessageContext etc. with >> the POJOCommand. I think we should retain it for the sake of simplicity of >> use. >> >> I'm +1 to deprecate the rest of the mediators. >> >> Thanks, >> >> Vidura >> >> >> >> On 9 December 2015 at 12:11, Kasun Indrasiri <ka...@wso2.com> wrote: >> >>> Shall we deprecate following mediators in 4.10 release. >>> >>> *- Callout mediator :* >>> All the callout functionality is supported with 'call' mediator with >>> blocking=true. Having two similar mediators will be create a bit of a >>> confusion. >>> >>> *- DBReport/DBLookup mediator* >>> These mediators offer very limited functionality and we always recommend >>> to integrate with databases with the use of DSS (using a separate DSS or >>> using DSS features inside ESB) >>> >>> *- Bean, POJOCommand, Spring* : Rarely used mediators and no active >>> development happens on these. >>> *- Router* : Same as filter mediator, so no use of having this. >>> *- In, Out * : Rarely used and often not required with the new >>> call/respond mediator approach. >>> >>> Any comments on these or any other features that we should deprecate >>> from 4.10 release? >>> >>> Thanks, >>> Kasun. >>> >>> -- >>> Kasun Indrasiri >>> Software Architect >>> WSO2, Inc.; http://wso2.com >>> lean.enterprise.middleware >>> >>> cell: +94 77 556 5206 >>> Blog : http://kasunpanorama.blogspot.com/ >>> >>> _______________________________________________ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Vidura Gamini Abhaya, Ph.D. >> Director of Engineering >> M:+94 77 034 7754 >> E: vid...@wso2.com >> >> WSO2 Inc. (http://wso2.com) >> lean.enterprise.middleware >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Kathees > Software Engineer, > email: kath...@wso2.com > mobile: +94772596173 > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Viraj Senevirathne Software Engineer; WSO2, Inc. Mobile : +94 71 958 0269 Email : vir...@wso2.com
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
