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).

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
>>>> 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
>>
>>
>
>
> --
> *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
> 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

Reply via email to