IMO best option in that case is have connectors supporting different spring versions, similar to what we are doing for EJBs. Having a mediator will only limit for single version.
On Thu, Dec 10, 2015 at 11:35 AM, Maheeka Jayasuriya <[email protected]> wrote: > 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 > > -- Best Regards, Malaka Silva Senior Tech Lead M: +94 777 219 791 Tel : 94 11 214 5345 Fax :94 11 2145300 Skype : malaka.sampath.silva LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77 Blog : http://mrmalakasilva.blogspot.com/ WSO2, Inc. lean . enterprise . middleware http://www.wso2.com/ http://www.wso2.com/about/team/malaka-silva/ <http://wso2.com/about/team/malaka-silva/> https://store.wso2.com/store/ Save a tree -Conserve nature & Save the world for your future. Print this email only if it is absolutely necessary.
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
