@Kathees : Can we verify NTLM use cases with Call mediator + blocking behavior? I guess it should work out of box as we also reuse the same blocking sender code?
For DB* mediators, I guess we can clearly mention in the docs that these mediators can be only used for very limited kind of DB operations but not for any complex DB integrations we must use DSS. And we won't any such features to DB* mediators. POJO/Spring mediators seems to need more attention :) and we should enhance them with proper use case docs. WDYT? On Fri, Dec 11, 2015 at 1:28 AM, Dulitha Wijewantha <duli...@wso2.com> wrote: > > > On Thu, Dec 10, 2015 at 1:26 AM, Vidura Gamini Abhaya <vid...@wso2.com> > wrote: > >> Hi Isuru, >> >> I've used it in a mediation sequence where I use a POJO to generate a >> unique customer id given a couple of parameters and there's a checksum >> added to the end. I already had written this code and it was quite simple >> and straightforward to reuse it with a POJOCommand mediator. I feel the >> simplicity of it is a welcome feature, where reading and setting values in >> MessageContext is automatically handled for me. >> >> I don't know whether a single usage case is enough to make the case to >> keep it. However, if we decide to keep it though, I suggest that we improve >> the documentation on it. I had to dig around to find out how the what the >> different actions mean. It wasn't clear to me in the docs (I believe most >> of the content is carried forward from Syanpse). >> > > +1 for deprecating POJO Mediator. The problem I find with the above > approach is that - there is an alternative way of doing it (using class > mediators). Not having multiple options (to do the same thing) in a > configurational language makes it easier for development, maintenance, > training etc. An example will be - POJOMediator can use expressions where > Class mediators you can't (making things confusing). It's better to push > the point home saying - the way to write custom code in the ESB (if you > have to) is using a class mediator and the message context api. > > Apart from that - I believe in the POJO mediator we create multiple > objects in the heap? Where as in the class mediator we just create once > instance. Am I correct on this observation? > > I am -1 for deprecating Db mediators. Like Malaka said, they are very > useful in scenarios where people want to connect to databases (also can be > used in conjunction with cache mediator for performance). > > >> >> Thanks and Regards, >> >> Vidura >> >> >> >> On 10 December 2015 at 10:57, Isuru Udana <isu...@wso2.com> wrote: >> >>> Hi Kathees, >>> >>> I think we should do a comparison once more to make sure that we have >>> covered everything before removing Callout. NTLM one which Harshana pointed >>> out may be due to absence of initClientOptions configuration option. >>> >>> Hi Vidura, >>> Point you raised on the POJOCommand mediator is really interesting. We >>> haven't seen any usage of that over years. But now we found at least one >>> user who has found it useful. Thanks for pointing that out. So we should >>> reconsider how useful it is. >>> >>> Thanks. >>> >>> >>> >>> 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 >>>>>> architect...@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 >>>>> architect...@wso2.org >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Kathees >>>> Software Engineer, >>>> email: kath...@wso2.com >>>> mobile: +94772596173 >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> architect...@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> *Isuru Udana* >>> Associate Technical Lead >>> WSO2 Inc.; http://wso2.com >>> email: isu...@wso2.com cell: +94 77 3791887 >>> blog: http://mytecheye.blogspot.com/ >>> >>> _______________________________________________ >>> Architecture mailing list >>> architect...@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 >> >> _______________________________________________ >> Dev mailing list >> Dev@wso2.org >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> > > > -- > Dulitha Wijewantha (Chan) > Software Engineer - Mobile Development > WSO2 Inc > Lean.Enterprise.Middleware > * ~Email duli...@wso2.com <duli...@wso2mobile.com>* > * ~Mobile +94712112165 <%2B94712112165>* > * ~Website dulitha.me <http://dulitha.me>* > * ~Twitter @dulitharw <https://twitter.com/dulitharw>* > *~Github @dulichan <https://github.com/dulichan>* > *~SO @chan <http://stackoverflow.com/users/813471/chan>* > > _______________________________________________ > Dev mailing list > Dev@wso2.org > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
