Hi, I've observed spring mediator being used extensively in situations where maintaining the domain model useful (class mediators are the alternative with a POJO domain model). This allows maintainability and is easily extensible. However, Spring mediator right now does not explore best of Spring capabilities, also because we are using spring 1.2.8 where as latest is 4.2.X.
It might be worthwhile to retain Spring mediator if we can upgrade the framework and explore more options, but depends on the validity of use cases. Thanks, Maheeka Maheeka Jayasuriya Software Engineer Mobile : +94777750661 On Thu, Dec 10, 2015 at 11:03 AM, Viraj Senevirathne <[email protected]> wrote: > 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 <[email protected]> > 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 <[email protected]> >> 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 <[email protected]> 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 >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Vidura Gamini Abhaya, Ph.D. >>> Director of Engineering >>> M:+94 77 034 7754 >>> E: [email protected] >>> >>> WSO2 Inc. (http://wso2.com) >>> lean.enterprise.middleware >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Kathees >> Software Engineer, >> email: [email protected] >> mobile: +94772596173 >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Viraj Senevirathne > Software Engineer; WSO2, Inc. > > Mobile : +94 71 958 0269 > Email : [email protected] > > _______________________________________________ > Dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/dev > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
