Re: [Dev] [Architecture] [ESB] Deprecated features in ESB 4.10

[Malaka Silva]

+1 except  DBReport/DBLookup mediators

On Wed, Dec 9, 2015 at 2:00 PM, Yumani Ranaweera  wrote:

> Is it possible to provide sufficient documentation to help the customers
> who would be migrating in future.
>
> Thanks,
> Yumani
>
>
> On Wed, Dec 9, 2015 at 1:45 PM, Chanaka Fernando 
> wrote:
>
>> *- 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.
>>
>> It will make a lot of confusion when we have more than one mediators to
>> do the same thing. Therefore, better to deprecate this mediator.
>>
>> *- 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)
>>
>> Even though this mediator has been used by some customers, they are using
>> that for very limited functionality and we always suggest them to use DSS
>> as Kasun mentioned. If users really want to connect to a database, they can
>> easily write a simple class mediator.
>>
>> *- 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.
>>
>> +1 for deprecating these mediators.
>>
>> With the new DAS integration, we can deprecate BAM mediator since we have
>> the PublishEvent mediator.
>>
>> On Wed, Dec 9, 2015 at 6:41 AM, Kasun Indrasiri  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/
>>>
>>
>>
>>
>> --
>> Thank you and Best Regards,
>> Chanaka Fernando
>> Senior Technical Lead
>> WSO2, Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> mobile: +94 773337238
>> Blog : http://soatutorials.blogspot.com
>> LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0
>> Twitter:https://twitter.com/chanakaudaya
>>
>>
>>
>>
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
>
>
> *Yumani Ranaweera* | Technical Lead
> Technical Support- Colombo
> WSO2 Inc. |  http://wso2.com
> Blog: http://yumani.blogspot.com/
> Mob: + 94 95242
>
> ___
> Architecture mailing list
> architect...@wso2.org
> 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/

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.
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [ESB] Deprecated features in ESB 4.10

[Kasun Indrasiri]

On Wed, Dec 9, 2015 at 3:32 PM, Malaka Silva  wrote:

> +1 except  DBReport/DBLookup mediators
>
> DBReport and DBLookup only offer a very limited set of capabilities. IMO,
for any real integration scenario, we can't use them.  :).

> On Wed, Dec 9, 2015 at 2:00 PM, Yumani Ranaweera  wrote:
>
>> Is it possible to provide sufficient documentation to help the customers
>> who would be migrating in future.
>>
>> Thanks,
>> Yumani
>>
>>
>> On Wed, Dec 9, 2015 at 1:45 PM, Chanaka Fernando 
>> wrote:
>>
>>> *- 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.
>>>
>>> It will make a lot of confusion when we have more than one mediators to
>>> do the same thing. Therefore, better to deprecate this mediator.
>>>
>>> *- 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)
>>>
>>> Even though this mediator has been used by some customers, they are
>>> using that for very limited functionality and we always suggest them to use
>>> DSS as Kasun mentioned. If users really want to connect to a database, they
>>> can easily write a simple class mediator.
>>>
>>> *- 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.
>>>
>>> +1 for deprecating these mediators.
>>>
>>> With the new DAS integration, we can deprecate BAM mediator since we
>>> have the PublishEvent mediator.
>>>
>>> On Wed, Dec 9, 2015 at 6:41 AM, Kasun Indrasiri  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/

>>>
>>>
>>>
>>> --
>>> Thank you and Best Regards,
>>> Chanaka Fernando
>>> Senior Technical Lead
>>> WSO2, Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> mobile: +94 773337238
>>> Blog : http://soatutorials.blogspot.com
>>> LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0
>>> Twitter:https://twitter.com/chanakaudaya
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>>
>>
>> *Yumani Ranaweera* | Technical Lead
>> Technical Support- Colombo
>> WSO2 Inc. |  http://wso2.com
>> Blog: http://yumani.blogspot.com/
>> Mob: + 94 95242
>>
>> ___
>> Architecture mailing list
>> architect...@wso2.org
>> 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/
> 
> 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.
>



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

Re: [Dev] [Architecture] [ESB] Deprecated features in ESB 4.10

[Malaka Silva]

In my experience using ​DB mediator we can cover some of the use cases
using ESB out of the box, which I find very handy.

Also use case of integrating with stored procs can easily covered with
this.

However there are limits like batch update or getting multiple rows.

​I guess we can argue both ways. IMO we should keep these mediators since
it'll become handy for some use cases :)

On Wed, Dec 9, 2015 at 4:58 PM, Kasun Indrasiri  wrote:

>
>
> On Wed, Dec 9, 2015 at 3:32 PM, Malaka Silva  wrote:
>
>> +1 except  DBReport/DBLookup mediators
>>
>> DBReport and DBLookup only offer a very limited set of capabilities. IMO,
> for any real integration scenario, we can't use them.  :).
>
>> On Wed, Dec 9, 2015 at 2:00 PM, Yumani Ranaweera  wrote:
>>
>>> Is it possible to provide sufficient documentation to help the customers
>>> who would be migrating in future.
>>>
>>> Thanks,
>>> Yumani
>>>
>>>
>>> On Wed, Dec 9, 2015 at 1:45 PM, Chanaka Fernando 
>>> wrote:
>>>
 *- 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.

 It will make a lot of confusion when we have more than one mediators to
 do the same thing. Therefore, better to deprecate this mediator.

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

 Even though this mediator has been used by some customers, they are
 using that for very limited functionality and we always suggest them to use
 DSS as Kasun mentioned. If users really want to connect to a database, they
 can easily write a simple class mediator.

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

 +1 for deprecating these mediators.

 With the new DAS integration, we can deprecate BAM mediator since we
 have the PublishEvent mediator.

 On Wed, Dec 9, 2015 at 6:41 AM, Kasun Indrasiri  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/
>



 --
 Thank you and Best Regards,
 Chanaka Fernando
 Senior Technical Lead
 WSO2, Inc.; http://wso2.com
 lean.enterprise.middleware

 mobile: +94 773337238
 Blog : http://soatutorials.blogspot.com
 LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0
 Twitter:https://twitter.com/chanakaudaya





 ___
 Dev mailing list
 Dev@wso2.org
 http://wso2.org/cgi-bin/mailman/listinfo/dev


>>>
>>>
>>> --
>>>
>>>
>>> *Yumani Ranaweera* | Technical Lead
>>> Technical Support- Colombo
>>> WSO2 Inc. |  http://wso2.com
>>> Blog: http://yumani.blogspot.com/
>>> Mob: + 94 95242
>>>
>>> ___
>>> Architecture mailing list
>>> architect...@wso2.org
>>> 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/
>> 
>> https://store.wso2.com/store/
>>
>> Save a tree -Conserve nature & Save the world for your future. Print this
>> em

Re: [Dev] [Architecture] [ESB] Deprecated features in ESB 4.10

[Harshana Eranga Martin]

Hi Kasun,

Please see the comments inline.

Thanks and Regards,
Harshana
--
Harshana Eranga Martin

Committer - Eclipse ECF: http://www.eclipse.org/ecf/
Blog: http://harshana05.blogspot.com
Profile: https://www.google.com/profiles/harshana05

On 9 December 2015 at 17:41, Kasun Indrasiri  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.
>

Can we use the Call mediator with blocking=true instead of Callout mediator
for the NTLM scenarios?

I have tried a NTLM scenario recently with Call mediator and blocking=true
in ESB 4.9.0 but it didn't work while the Callout mediator works fine for
the same scenario. I also assumed Call mediator would work but it didn't.
Can you please check and verify?



> *- 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
>
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [ESB] Deprecated features in ESB 4.10

[Isuru Udana]

Hi Harshana,

On Wed, Dec 9, 2015 at 6:46 PM, Harshana Eranga Martin  wrote:

> Hi Kasun,
>
> Please see the comments inline.
>
> Thanks and Regards,
> Harshana
> --
> Harshana Eranga Martin
>
> Committer - Eclipse ECF: http://www.eclipse.org/ecf/
> Blog: http://harshana05.blogspot.com
> Profile: https://www.google.com/profiles/harshana05
>
> On 9 December 2015 at 17:41, Kasun Indrasiri  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.
>>
>
> Can we use the Call mediator with blocking=true instead of Callout
> mediator for the NTLM scenarios?
>
> I have tried a NTLM scenario recently with Call mediator and blocking=true
> in ESB 4.9.0 but it didn't work while the Callout mediator works fine for
> the same scenario. I also assumed Call mediator would work but it didn't.
> Can you please check and verify?
>
> If that the case, we need to fix that bug.

>
>
>> *- 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
>>
>>
>
> ___
> 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/
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [ESB] Deprecated features in ESB 4.10

[Vanjikumaran Sivajothy]

Is it going to be complete functional Deprecate? If yes, there will be not
forward compatibility during the upgrades.

On Wed, Dec 9, 2015 at 10:23 AM, Isuru Udana  wrote:

> Hi Harshana,
>
> On Wed, Dec 9, 2015 at 6:46 PM, Harshana Eranga Martin <
> harshan...@gmail.com> wrote:
>
>> Hi Kasun,
>>
>> Please see the comments inline.
>>
>> Thanks and Regards,
>> Harshana
>> --
>> Harshana Eranga Martin
>>
>> Committer - Eclipse ECF: http://www.eclipse.org/ecf/
>> Blog: http://harshana05.blogspot.com
>> Profile: https://www.google.com/profiles/harshana05
>>
>> On 9 December 2015 at 17:41, Kasun Indrasiri  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.
>>>
>>
>> Can we use the Call mediator with blocking=true instead of Callout
>> mediator for the NTLM scenarios?
>>
>> I have tried a NTLM scenario recently with Call mediator and
>> blocking=true in ESB 4.9.0 but it didn't work while the Callout mediator
>> works fine for the same scenario. I also assumed Call mediator would work
>> but it didn't. Can you please check and verify?
>>
>> If that the case, we need to fix that bug.
>
>>
>>
>>> *- 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
>>>
>>>
>>
>> ___
>> 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
>
>


-- 
Vanjikumaran Sivajothy
*Associate Technical Lead*
*WSO2 Inc. http://wso2.com *
*USA Mobile **+1-812-361-1286*
*Srilanka Mobile:+94-777-219-209*
[image: Facebook]  [image: Twitter]
 [image: LinkedIn]
 [image:
Blogger]  [image: SlideShare]


This communication may contain privileged or other confidential information
and is intended exclusively for the addressee/s. If you are not the
intended recipient/s, or believe that you may have received this
communication in error, please reply to the sender indicating that fact and
delete the copy you received and in addition, you should not print,
copy, re-transmit, disseminate, or otherwise use the information contained
in this communication. Internet communications cannot be guaranteed to be
timely, secure, error or virus-free. The sender does not accept liability
for any errors or omissions
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [ESB] Deprecated features in ESB 4.10

[Vidura Gamini Abhaya]

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  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
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [ESB] Deprecated features in ESB 4.10

[Kathees Rajendram]

+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 
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  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
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [ESB] Deprecated features in ESB 4.10

[Isuru Udana]

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 
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 
> 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  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/
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [ESB] Deprecated features in ESB 4.10

[Viraj Senevirathne]

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


-- 
Viraj Senevirathne
Software Engineer; WSO2, Inc.

Mobile : +94 71 958 0269
Email : vir...@wso2.com
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [ESB] Deprecated features in ESB 4.10

[Maheeka Jayasuriya]

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 : +9450661

On Thu, Dec 10, 2015 at 11:03 AM, Viraj Senevirathne 
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 
> 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 
>> 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  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
>>
>>
>
>
> --
> Viraj Senevirathne
> Software Engineer; WSO2, Inc.
>
> Mobile : +94 71 958 0269
> Email : vir...@wso2.com
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [ESB] Deprecated features in ESB 4.10

[Malaka Silva]

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 
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 : +9450661
>
> On Thu, Dec 10, 2015 at 11:03 AM, Viraj Senevirathne 
> 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 
>> 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 
>>> 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  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
>>>
>>>
>>
>>
>> --
>> Viraj Senevirathne
>> Software Engineer; WSO2, Inc.
>>
>> Mobile : +94 71 958 0269
>> Email : vir...@wso2.com
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http:

Re: [Dev] [Architecture] [ESB] Deprecated features in ESB 4.10

[Vidura Gamini Abhaya]

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

Re: [Dev] [Architecture] [ESB] Deprecated features in ESB 4.10

[Dulitha Wijewantha]

On Thu, Dec 10, 2015 at 1:26 AM, Vidura Gamini Abhaya 
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  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 
>> 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 
>>> 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  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
>

Re: [Dev] [Architecture] [ESB] Deprecated features in ESB 4.10

[Kasun Indrasiri]

@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 
wrote:

>
>
> On Thu, Dec 10, 2015 at 1:26 AM, Vidura Gamini Abhaya 
> 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  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 
>>> 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 
 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  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.
>> *-

Re: [Dev] [Architecture] [ESB] Deprecated features in ESB 4.10

[Cyril Rognon]

Hi

DB mediator can be handy as you said but it is a bad  practice to query the
DB right from the Esb. It is against the low coupling principles that makes
integration  layer agile and   thin and scalable etc.

DSS is setup in two  minutes and can fulfill your needs   out of the box.

Maybe we should provide a migration tool to turn  DBMediator usage into
Daraservices operation  call.  One could even  generate the dbs Dataservice
definition from the DBMediator.

+1 for deprecating these  mediators.  Setup some tool or complete
documentation to migrate existing usage.

Thanks,
Cyril
Le 9 déc. 2015 13:55, "Malaka Silva"  a écrit :

> In my experience using ​DB mediator we can cover some of the use cases
> using ESB out of the box, which I find very handy.
>
> Also use case of integrating with stored procs can easily covered with
> this.
>
> However there are limits like batch update or getting multiple rows.
>
> ​I guess we can argue both ways. IMO we should keep these mediators since
> it'll become handy for some use cases :)
>
> On Wed, Dec 9, 2015 at 4:58 PM, Kasun Indrasiri  wrote:
>
>>
>>
>> On Wed, Dec 9, 2015 at 3:32 PM, Malaka Silva  wrote:
>>
>>> +1 except  DBReport/DBLookup mediators
>>>
>>> DBReport and DBLookup only offer a very limited set of capabilities.
>> IMO, for any real integration scenario, we can't use them.  :).
>>
>>> On Wed, Dec 9, 2015 at 2:00 PM, Yumani Ranaweera 
>>> wrote:
>>>
 Is it possible to provide sufficient documentation to help the
 customers who would be migrating in future.

 Thanks,
 Yumani


 On Wed, Dec 9, 2015 at 1:45 PM, Chanaka Fernando 
 wrote:

> *- 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.
>
> It will make a lot of confusion when we have more than one mediators
> to do the same thing. Therefore, better to deprecate this mediator.
>
> *- 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)
>
> Even though this mediator has been used by some customers, they are
> using that for very limited functionality and we always suggest them to 
> use
> DSS as Kasun mentioned. If users really want to connect to a database, 
> they
> can easily write a simple class mediator.
>
> *- 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.
>
> +1 for deprecating these mediators.
>
> With the new DAS integration, we can deprecate BAM mediator since we
> have the PublishEvent mediator.
>
> On Wed, Dec 9, 2015 at 6:41 AM, Kasun Indrasiri 
> 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/
>>
>
>
>
> --
> Thank you and Best Regards,
> Chanaka Fernando
> Senior Technical Lead
> WSO2, Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: +94 773337238
> Blog : http://soatutorials.blogspot.com
> LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0
> Twitter:https://twitter.com/chanakaudaya
>
>
>
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


 --


 *Yumani Ranaweera* | Technical Lead
 Technical Support- Colombo
 WSO2 Inc. |  http://wso2.com

Re: [Dev] [Architecture] [ESB] Deprecated features in ESB 4.10

[Amila Maha Arachchi]

Have you seen *Enqueue* and *RMSequence* mediators being used when
implementing mediation logics?

On Wed, Dec 9, 2015 at 12:11 PM, Kasun Indrasiri  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
>
>


-- 
*Amila Maharachchi*
Senior Technical Lead
WSO2, Inc.; http://wso2.com

Blog: http://maharachchi.blogspot.com
Mobile: +94719371446
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [ESB] Deprecated features in ESB 4.10

[Isuru Udana]

Hi Amila,

On Fri, Dec 18, 2015 at 11:12 AM, Amila Maha Arachchi 
wrote:

> Have you seen *Enqueue* and *RMSequence* mediators being used when
> implementing mediation logics?
>
We have already removed RMSequence mediator in 4.9.0.
I haven't seen anyone using Enqueue Mediator in a real use case.

I think we should deprecate Topic feature and Event Mediator as well.

Thanks.

>
> On Wed, Dec 9, 2015 at 12:11 PM, Kasun Indrasiri  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
>>
>>
>
>
> --
> *Amila Maharachchi*
> Senior Technical Lead
> WSO2, Inc.; http://wso2.com
>
> Blog: http://maharachchi.blogspot.com
> Mobile: +94719371446
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
*Isuru Udana*
Associate Technical Lead
WSO2 Inc.; http://wso2.com
email: isu...@wso2.com cell: +94 77 3791887
blog: http://mytecheye.blogspot.com/
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [ESB] Deprecated features in ESB 4.10

[Prabath Abeysekera]

I agree with Cyril.

In addition to what's already been mentioned, I don't think it's a good
idea to make mediation threads blocked for database calls, etc via
DBLookup/DBReport for longer periods of time, as most of the queries that
are usually being used in pretty much any practical enterprise integration
scenario would be time-consuming, particularly as respective data-stores
get occupied of large volumes of data, over time. ESB, as quite being used
as a backbone of any system that connects multiple disparate systems
together via mediation, etc, letting its core blocked for such an
environment isn't quite good, IMO. Instead, I believe, a better option
would be to delegate the same responsibility to the data layer, which can
then be scaled up and tuned to deal with similar instances.

Cheers,
Prabath

On Wed, Dec 16, 2015 at 12:05 PM, Cyril Rognon 
wrote:

> Hi
>
> DB mediator can be handy as you said but it is a bad  practice to query
> the DB right from the Esb. It is against the low coupling principles that
> makes integration  layer agile and   thin and scalable etc.
>
> DSS is setup in two  minutes and can fulfill your needs   out of the box.
>
> Maybe we should provide a migration tool to turn  DBMediator usage into
> Daraservices operation  call.  One could even  generate the dbs Dataservice
> definition from the DBMediator.
>
> +1 for deprecating these  mediators.  Setup some tool or complete
> documentation to migrate existing usage.
>
> Thanks,
> Cyril
> Le 9 déc. 2015 13:55, "Malaka Silva"  a écrit :
>
>> In my experience using ​DB mediator we can cover some of the use cases
>> using ESB out of the box, which I find very handy.
>>
>> Also use case of integrating with stored procs can easily covered with
>> this.
>>
>> However there are limits like batch update or getting multiple rows.
>>
>> ​I guess we can argue both ways. IMO we should keep these mediators since
>> it'll become handy for some use cases :)
>>
>> On Wed, Dec 9, 2015 at 4:58 PM, Kasun Indrasiri  wrote:
>>
>>>
>>>
>>> On Wed, Dec 9, 2015 at 3:32 PM, Malaka Silva  wrote:
>>>
 +1 except  DBReport/DBLookup mediators

 DBReport and DBLookup only offer a very limited set of capabilities.
>>> IMO, for any real integration scenario, we can't use them.  :).
>>>
 On Wed, Dec 9, 2015 at 2:00 PM, Yumani Ranaweera 
 wrote:

> Is it possible to provide sufficient documentation to help the
> customers who would be migrating in future.
>
> Thanks,
> Yumani
>
>
> On Wed, Dec 9, 2015 at 1:45 PM, Chanaka Fernando 
> wrote:
>
>> *- 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.
>>
>> It will make a lot of confusion when we have more than one mediators
>> to do the same thing. Therefore, better to deprecate this mediator.
>>
>> *- 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)
>>
>> Even though this mediator has been used by some customers, they are
>> using that for very limited functionality and we always suggest them to 
>> use
>> DSS as Kasun mentioned. If users really want to connect to a database, 
>> they
>> can easily write a simple class mediator.
>>
>> *- 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.
>>
>> +1 for deprecating these mediators.
>>
>> With the new DAS integration, we can deprecate BAM mediator since we
>> have the PublishEvent mediator.
>>
>> On Wed, Dec 9, 2015 at 6:41 AM, Kasun Indrasiri 
>> 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 shou

Re: [Dev] [Architecture] [ESB] Deprecated features in ESB 4.10

[Kasun Indrasiri]

Shall we finalize the things that are going to deprecate in ESB 5?
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev