[Architecture] License header in confi files

[Afkham Azeez]

I was wondering whether we really need the license header in config files.
These are files that will be edited by the users, and it really doesn't
make much sense to have the license there, and also it makes the files
unnecessarily long.

How about removing the license headers from config files, going forward?

-- 
*Afkham Azeez*
Senior Director, Platform Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919blog: **http://blog.afkham.org*
<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*
<http://twitter.com/afkham_azeez>
*linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] License header in confi files

[Afkham Azeez]

On Wed, Jun 28, 2017 at 11:59 AM, KasunG Gajasinghe  wrote:

>
> +1 Azeez. And, we should not blindly add them either. In the latest
> carbon-commons version, the INFO message box displays the license text. [1]
> :(
>

Yes, I have not seen many other projects adding license headers to conf
files users edit. I think we should implement this for all future releases.

>
> [1] https://github.com/wso2/carbon-commons/issues/273
>
> On Wed, Jun 28, 2017 at 11:55 AM, Afkham Azeez  wrote:
>
>> I was wondering whether we really need the license header in config
>> files. These are files that will be edited by the users, and it really
>> doesn't make much sense to have the license there, and also it makes the
>> files unnecessarily long.
>>
>> How about removing the license headers from config files, going forward?
>>
>> --
>> *Afkham Azeez*
>> Senior Director, Platform Architecture; WSO2, Inc.; http://wso2.com
>> Member; Apache Software Foundation; http://www.apache.org/
>> * <http://www.apache.org/>*
>> *email: **az...@wso2.com* 
>> * cell: +94 77 3320919 <077%20332%200919>blog: **http://blog.afkham.org*
>> <http://blog.afkham.org>
>> *twitter: **http://twitter.com/afkham_azeez*
>> <http://twitter.com/afkham_azeez>
>> *linked-in: **http://lk.linkedin.com/in/afkhamazeez
>> <http://lk.linkedin.com/in/afkhamazeez>*
>>
>> *Lean . Enterprise . Middleware*
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
>
> *Kasun Gajasinghe*Associate Technical Lead, WSO2 Inc.
> email: kasung AT spamfree wso2.com
> linked-in: http://lk.linkedin.com/in/gajasinghe
> blog: http://kasunbg.org
> phone: +1 650-745-4499 <+1%20650-745-4499>, 77 678 0813
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Afkham Azeez*
Senior Director, Platform Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919blog: **http://blog.afkham.org*
<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*
<http://twitter.com/afkham_azeez>
*linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IAM] SCIM 2.0 Outbound Connector

[Afkham Azeez]

tpClient  but
>>>>>>> better to give a try with swagger doc as well.
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>1. Separate SCIM 2.0 client from [1]
>>>>>>>>>2. Separate SCIM 2.0 client from [2]
>>>>>>>>>3. Use swagger doc [3] to generate client
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> [1] https://github.com/wso2-incubator/scim2-compliance-test-suite
>>>>>>>>> [2] https://github.com/HansageeSJ/scim-client
>>>>>>>>> [3] https://wso2.org/jira/browse/IDENTITY-5695
>>>>>>>>>
>>>>>>>>> Appreciate any suggestions.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best Regards
>>>>>>>>> Isuranga Perera
>>>>>>>>>
>>>>>>>>> On Fri, Oct 13, 2017 at 9:42 AM, Gayan Gunawardana >>>>>>>> > wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, Oct 12, 2017 at 5:33 PM, Johann Nallathamby <
>>>>>>>>>> joh...@wso2.com> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Oct 12, 2017 at 1:28 PM, Isuranga Perera <
>>>>>>>>>>> isurangamper...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi IAM Team,
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Currently, there is no $subject. Therefore I'm looking at
>>>>>>>>>>>> implementing a SCIM2 Outbound Connector. I'm looking at
>>>>>>>>>>>> identity-outbound-provisioning-scim [1]
>>>>>>>>>>>> and scim2-compliance-test-suite [2]. Appreciate further
>>>>>>>>>>>> suggestions.
>>>>>>>>>>>>
>>>>>>>>>>> Hi Isuranga,
>>>>>>>>>>
>>>>>>>>>> It should be same as [1] you just have to think SCIM provider is
>>>>>>>>>> version 2 and send http requests according to SCIM2 format. As a 
>>>>>>>>>> starting
>>>>>>>>>> point you can setup existing SCIM provisioning connector and debug 
>>>>>>>>>> from
>>>>>>>>>> point [1] so you will understand the flow.
>>>>>>>>>>
>>>>>>>>>> [1] https://github.com/wso2-extensions/identity-outbound-provisi
>>>>>>>>>> oning-scim/blob/master/components/org.wso2.carbon.identity.p
>>>>>>>>>> rovisioning.connector.scim/src/main/java/org/wso2/carbon/ide
>>>>>>>>>> ntity/provisioning/connector/scim/SCIMProvisioningConnector.
>>>>>>>>>> java#L99
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> [1] https://github.com/wso2-extensions/identity-outbound-pro
>>>>>>>>>>>> visioning-scim
>>>>>>>>>>>> [2] https://github.com/wso2-incubator/scim2-compliance-test-
>>>>>>>>>>>> suite
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Best Regards
>>>>>>>>>>>> Isuranga Perera
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ___
>>>>>>>>>>>> Architecture mailing list
>>>>>>>>>>>> Architecture@wso2.org
>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Thanks & Regards,
>>>>>>>>>>>
>>>>>>>>>>> *Johann Dilantha Nallathamby*
>>>>>>>>>>> Senior Lead Solutions Engineer
>>>>>>>>>>> WSO2, Inc.
>>>>>>>>>>> lean.enterprise.middleware
>>>>>>>>>>>
>>>>>>>>>>> Mobile - *+9476950*
>>>>>>>>>>> Blog - *http://nallaa.wordpress.com
>>>>>>>>>>> <http://nallaa.wordpress.com>*
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Gayan Gunawardana
>>>>>>>>>> Senior Software Engineer; WSO2 Inc.; http://wso2.com/
>>>>>>>>>> Email: ga...@wso2.com
>>>>>>>>>> Mobile: +94 (71) 8020933
>>>>>>>>>>
>>>>>>>>>> ___
>>>>>>>>>> Architecture mailing list
>>>>>>>>>> Architecture@wso2.org
>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Thanks & Regards,
>>>>>>>>
>>>>>>>> *Johann Dilantha Nallathamby*
>>>>>>>> Senior Lead Solutions Engineer
>>>>>>>> WSO2, Inc.
>>>>>>>> lean.enterprise.middleware
>>>>>>>>
>>>>>>>> Mobile - *+9476950*
>>>>>>>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Gayan Gunawardana
>>>>>>> Senior Software Engineer; WSO2 Inc.; http://wso2.com/
>>>>>>> Email: ga...@wso2.com
>>>>>>> Mobile: +94 (71) 8020933
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Gayan Gunawardana
>>>>>> Senior Software Engineer; WSO2 Inc.; http://wso2.com/
>>>>>> Email: ga...@wso2.com
>>>>>> Mobile: +94 (71) 8020933
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Gayan Gunawardana
>>>> Senior Software Engineer; WSO2 Inc.; http://wso2.com/
>>>> Email: ga...@wso2.com
>>>> Mobile: +94 (71) 8020933
>>>>
>>>
>>>
>>>
>>> --
>>> Thanks & Regards,
>>>
>>> *Johann Dilantha Nallathamby*
>>> Senior Lead Solutions Engineer
>>> WSO2, Inc.
>>> lean.enterprise.middleware
>>>
>>> Mobile - *+9476950*
>>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
>>>
>>
>>
>>
>> --
>> Thanks & Regards,
>>
>> *Johann Dilantha Nallathamby*
>> Senior Lead Solutions Engineer
>> WSO2, Inc.
>> lean.enterprise.middleware
>>
>> Mobile - *+9476950*
>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
>>
>
>
>
> --
>
> Thanks & Best Regards,
>
> Maheshika Goonetilleke
> Senior Engineering Process Coordinator
>
> *WSO2 Inc*
> *email   : mahesh...@wso2.com *
> *mobile : +94 773 596707 <077%20359%206707>*
> *www: :http://wso2.com <http://wso2.com/>*lean . enterprise . middleware
>
>
>
>
>


-- 
*Afkham Azeez*
Senior Director, Platform Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919blog: **http://blog.afkham.org*
<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*
<http://twitter.com/afkham_azeez>
*linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IAM] SCIM 2.0 Outbound Connector

[Afkham Azeez]

On Tue, Nov 21, 2017 at 9:12 PM, Johann Nallathamby  wrote:

>
>
> On Tue, Nov 21, 2017 at 2:53 PM, Isura Karunaratne  wrote:
>
>> Repo name for outbound connector
>>
>>- * identity-outbound-provisioning-scim2*
>>
>> Repo name for the scim2 client.
>>
>>-
>> * identity-client-scim2 *
>>
>>
> +1 for above two repos.
>
> *@Azeez*: please approve above two repos in wso2-extensions.
>

Approved

>
>>-
>>
>>
>> @isuraranga,
>>
>> Why do we need the scim2-commons repo? Can't we use Charon for that?
>>
>
> Discussed offline with Isuranga and decided we can use Charon repo for
> those common packages because they are SCIM2 specific and not carbon
> specific. So no need scim2-common for now.
>
> Regards,
> Johann.
>
>
>>
>> Thanks
>> Isura.
>>
>> On Mon, Nov 20, 2017 at 3:04 PM, Afkham Azeez  wrote:
>>
>>> What is the repo name?
>>>
>>> On Tue, Nov 7, 2017 at 1:06 PM, Maheshika Goonetilleke <
>>> mahesh...@wso2.com> wrote:
>>>
>>>> Hi Azeez
>>>>
>>>> Please confirm.
>>>>
>>>> On Tue, Nov 7, 2017 at 11:23 AM, Johann Nallathamby 
>>>> wrote:
>>>>
>>>>> Hi Maheshika,
>>>>>
>>>>> Can we have following 3 repos for this project under wso2-extensions
>>>>> organization?
>>>>>
>>>>> 1. *identity-outbound-provisioning-scim2*
>>>>>
>>>>> For the outbound connector
>>>>>
>>>>> 2. *identity-scim2-common*
>>>>>
>>>>> For common utilities for inbound and outbound connectors. E.g.
>>>>> AttributeMapper class in inbound connector which is needed for outbound
>>>>> connector as well.
>>>>>
>>>>> 3. *identity-client-scim2*
>>>>>
>>>>> For SCIM2 client generated using SCIM2 swagger files. This will be
>>>>> used by outbound connector as well as can be used by anyone as standalone
>>>>> client. Ideally this should be used for the scim2 compliance test suite as
>>>>> well, but have failed to do so.
>>>>>
>>>>> Regards,
>>>>> Johann.
>>>>>
>>>>> On Mon, Oct 16, 2017 at 2:21 PM, Johann Nallathamby 
>>>>> wrote:
>>>>>
>>>>>> Yes, I also think we need to take the approach of using the Swagger
>>>>>> files and generate SDK because that is what standard Rest API world will 
>>>>>> be
>>>>>> doing. We can find any issues early.
>>>>>>
>>>>>> Regards,
>>>>>> Johann.
>>>>>>
>>>>>> On Mon, Oct 16, 2017 at 2:18 PM, Gayan Gunawardana 
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Oct 16, 2017 at 1:21 PM, Isuranga Perera <
>>>>>>> isurangamper...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi Gayan,
>>>>>>>>
>>>>>>>> In that case, I'll try to create an SDK from swagger and use it as
>>>>>>>> the client.
>>>>>>>>
>>>>>>> That would be great.
>>>>>>>
>>>>>>>>
>>>>>>>> Best Regards
>>>>>>>>
>>>>>>>> On Mon, Oct 16, 2017 at 9:12 AM, Gayan Gunawardana 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Since you are looking for abstraction layer, can implement
>>>>>>>>> something like [1] for SCIM2 as well.
>>>>>>>>>
>>>>>>>>> [1] https://github.com/wso2-extensions/identity-inbound-provisio
>>>>>>>>> ning-scim/blob/master/components/org.wso2.carbon.identity.sc
>>>>>>>>> im.common/src/main/java/org/wso2/carbon/identity/scim/common
>>>>>>>>> /impl/ProvisioningClient.java
>>>>>>>>>
>>>>>>>>> On Sun, Oct 15, 2017 at 11:16 PM, Gayan Gunawardana <
>>>>>>>>> ga...@wso2.com> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>

Re: [Architecture] [IAM] SCIM 2.0 Outbound Connector

[Afkham Azeez]

Now you need approval for 2 repos of 3 repos?

On Tue, Nov 21, 2017 at 2:53 PM, Isura Karunaratne  wrote:

> Repo name for outbound connector
>
>- * identity-outbound-provisioning-scim2*
>
> Repo name for the scim2 client.
>
>-
> * identity-client-scim2 *
>
>
> @isuraranga,
>
> Why do we need the scim2-commons repo? Can't we use Charon for that?
>
> Thanks
> Isura.
>
> On Mon, Nov 20, 2017 at 3:04 PM, Afkham Azeez  wrote:
>
>> What is the repo name?
>>
>> On Tue, Nov 7, 2017 at 1:06 PM, Maheshika Goonetilleke <
>> mahesh...@wso2.com> wrote:
>>
>>> Hi Azeez
>>>
>>> Please confirm.
>>>
>>> On Tue, Nov 7, 2017 at 11:23 AM, Johann Nallathamby 
>>> wrote:
>>>
>>>> Hi Maheshika,
>>>>
>>>> Can we have following 3 repos for this project under wso2-extensions
>>>> organization?
>>>>
>>>> 1. *identity-outbound-provisioning-scim2*
>>>>
>>>> For the outbound connector
>>>>
>>>> 2. *identity-scim2-common*
>>>>
>>>> For common utilities for inbound and outbound connectors. E.g.
>>>> AttributeMapper class in inbound connector which is needed for outbound
>>>> connector as well.
>>>>
>>>> 3. *identity-client-scim2*
>>>>
>>>> For SCIM2 client generated using SCIM2 swagger files. This will be used
>>>> by outbound connector as well as can be used by anyone as standalone
>>>> client. Ideally this should be used for the scim2 compliance test suite as
>>>> well, but have failed to do so.
>>>>
>>>> Regards,
>>>> Johann.
>>>>
>>>> On Mon, Oct 16, 2017 at 2:21 PM, Johann Nallathamby 
>>>> wrote:
>>>>
>>>>> Yes, I also think we need to take the approach of using the Swagger
>>>>> files and generate SDK because that is what standard Rest API world will 
>>>>> be
>>>>> doing. We can find any issues early.
>>>>>
>>>>> Regards,
>>>>> Johann.
>>>>>
>>>>> On Mon, Oct 16, 2017 at 2:18 PM, Gayan Gunawardana 
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Oct 16, 2017 at 1:21 PM, Isuranga Perera <
>>>>>> isurangamper...@gmail.com> wrote:
>>>>>>
>>>>>>> Hi Gayan,
>>>>>>>
>>>>>>> In that case, I'll try to create an SDK from swagger and use it as
>>>>>>> the client.
>>>>>>>
>>>>>> That would be great.
>>>>>>
>>>>>>>
>>>>>>> Best Regards
>>>>>>>
>>>>>>> On Mon, Oct 16, 2017 at 9:12 AM, Gayan Gunawardana 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Since you are looking for abstraction layer, can implement
>>>>>>>> something like [1] for SCIM2 as well.
>>>>>>>>
>>>>>>>> [1] https://github.com/wso2-extensions/identity-inbound-provisio
>>>>>>>> ning-scim/blob/master/components/org.wso2.carbon.identity.sc
>>>>>>>> im.common/src/main/java/org/wso2/carbon/identity/scim/common
>>>>>>>> /impl/ProvisioningClient.java
>>>>>>>>
>>>>>>>> On Sun, Oct 15, 2017 at 11:16 PM, Gayan Gunawardana >>>>>>> > wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sun, Oct 15, 2017 at 8:39 PM, Johann Nallathamby <
>>>>>>>>> joh...@wso2.com> wrote:
>>>>>>>>>
>>>>>>>>>> *[+ IsharaK, Omindu, Farasath]*
>>>>>>>>>>
>>>>>>>>>> On Sun, Oct 15, 2017 at 7:34 PM, Isuranga Perera <
>>>>>>>>>> isurangamper...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I went through the scim2-compliance-test-suite [1] source code,
>>>>>>>>>>> but I couldn't find an abstraction layer which separates the SCIM 2 
>>>>>>>>>>> client
>

Re: [Architecture] C5 clustering

[Afkham Azeez]

There is no such thing as C5 clustering. For each product, clustering would
mean a different thing. Some of the core decisions we have made related to
multi-tenancy include, each tenant will be running in separate
containers/processes and there will be no in-VM multi-tenancy.

So when it comes to clustering, you need to refer to the product specific
docs.

Thanks
Azeez

On Fri, Dec 22, 2017 at 12:08 PM, Lahiru Sandaruwan 
wrote:

> Hi All,
>
> Do we have any docs/ details on $subject?
>
> Thanks.
>
> --
> --
>
> Lahiru Sandaruwan
> Associate Technical Lead,
> WSO2 Inc., http://wso2.com
>
> lean.enterprise.middleware
>
> m: +1 901 530 2379 <+1%20901-530-2379>
> e: lahi...@wso2.com b: https://medium.com/@lahirugmg
> in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>
>


-- 
*Afkham Azeez*
Senior Director, Platform Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919blog: **http://blog.afkham.org*
<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*
<http://twitter.com/afkham_azeez>
*linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] C5 clustering

[Afkham Azeez]

No we don't encourage distributed caches anymore. As you may have heard "There
are only two hard things in Computer Science: cache invalidation and naming
things. -- Phil Karlton" :)

So you are supposed to use a product specific DB and if required, a local
cache.

Thanks
Azeez

On Fri, Dec 22, 2017 at 7:12 PM, Lahiru Sandaruwan  wrote:

> Thank you for the clarification Azeez. I believe each product has to build
> or use a library for distributed cache requirements. Isn’t it a strong case
> to have a common way of clustering?
>
> Thanks.
>
> On Fri, Dec 22, 2017 at 3:53 AM Afkham Azeez  wrote:
>
>> There is no such thing as C5 clustering. For each product, clustering
>> would mean a different thing. Some of the core decisions we have made
>> related to multi-tenancy include, each tenant will be running in separate
>> containers/processes and there will be no in-VM multi-tenancy.
>>
>> So when it comes to clustering, you need to refer to the product specific
>> docs.
>>
>> Thanks
>> Azeez
>>
>> On Fri, Dec 22, 2017 at 12:08 PM, Lahiru Sandaruwan 
>> wrote:
>>
>>> Hi All,
>>>
>>> Do we have any docs/ details on $subject?
>>>
>>> Thanks.
>>>
>>> --
>>> --
>>>
>>> Lahiru Sandaruwan
>>> Associate Technical Lead,
>>> WSO2 Inc., http://wso2.com
>>>
>>> lean.enterprise.middleware
>>>
>>> m: +1 901 530 2379 <+1%20901-530-2379>
>>> e: lahi...@wso2.com b: https://medium.com/@lahirugmg
>>> in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>>>
>>>
>>
>>
>> --
>> *Afkham Azeez*
>> Senior Director, Platform Architecture; WSO2, Inc.; http://wso2.com
>> Member; Apache Software Foundation; http://www.apache.org/
>> * <http://www.apache.org/>*
>> *email: **az...@wso2.com* 
>> * cell: +94 77 3320919 <077%20332%200919>blog: **http://blog.afkham.org*
>> <http://blog.afkham.org>
>> *twitter: **http://twitter.com/afkham_azeez*
>> <http://twitter.com/afkham_azeez>
>> *linked-in: **http://lk.linkedin.com/in/afkhamazeez
>> <http://lk.linkedin.com/in/afkhamazeez>*
>>
>> *Lean . Enterprise . Middleware*
>>
> --
> --
>
> Lahiru Sandaruwan
> Associate Technical Lead,
> WSO2 Inc., http://wso2.com
>
> lean.enterprise.middleware
>
> m: +1 901 530 2379 <+1%20901-530-2379>
> e: lahi...@wso2.com b: https://medium.com/@lahirugmg
> in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>
>


-- 
*Afkham Azeez*
Senior Director, Platform Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919blog: **http://blog.afkham.org*
<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*
<http://twitter.com/afkham_azeez>
*linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Get rid of java2wsdl, wsdl2java sh/bat scripts from IS 5.5.0 bin directory

[Afkham Azeez]

Yeah, please get rid of these. We discussed the same sometime back and I
was under the impression that these were already removed.

On Thu, Jan 11, 2018 at 7:52 AM, Sagara Gunathunga  wrote:

> IS bin directory contains following set of sh/bat files, ATM these are
> exists due to historical reasons only couldn't find any real usage. If
> there is no objection I would like to discard them from 5.5.0 WDYT ?
>
> java2wsdl.sh
> java2wsdl.bat
> wsdl2java.bat
> wsdl2java.sh
> tcpmon-1.0.jar
> tcpmon.sh
> tcpmon.bat
>
>
> Thanks !
> --
> Sagara Gunathunga
>
> Director; WSO2, Inc.;  http://wso2.com
> Linkedin; http://www.linkedin.com/in/ssagara
> Blog ;  http://ssagara.blogspot.com
> Mobile : +9471 <+94%2071%20565%209887>2149951
>
>


-- 
*Afkham Azeez*
Senior Director, Platform Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919blog: **http://blog.afkham.org*
<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*
<http://twitter.com/afkham_azeez>
*linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [X509 Authenticator] Certificate Revocation Verification with CRL and OCSP

[Afkham Azeez]

Approved

On Feb 12, 2018 10:26 AM, "Indunil Upeksha Rathnayake" 
wrote:

Hi Maheshika,

Can you please create a new git repository with the name "
identity-x509-revocation" under wso2-extensions, for moving this feature
implementation.

Thanks and Regards

On Wed, Jan 17, 2018 at 11:20 AM, Indunil Upeksha Rathnayake <
indu...@wso2.com> wrote:

> Hi,
>
> Please find the following considerations on proceeding with the CRL/OCSP
> certificate validation. Appreciate your ideas and comments on this.
>
> *Store root CA and intermediate CA certificates in registry*
>
>- As per the current implementation, trust stores which are having CA
>certificates that should be used for CRL and OCSP validation, can be
>configured file based as follows.
>
>
>
>http://wso2.org/project
>s/carbon/certificate-validation.xml
>">
>
>…….
>
>
>
>   *truststorePass="cacertspassword" type="JKS"/>*
>
>
>
>
>
>
>- In server start up and in tenant initial activation, all the
>certificates in the trust stores will added to the registry.
>
> Registry path : 
> *repository/security/certificate/certificate-authorities/ Issuer DN>/*
>
> Normalized Issuer DN : UTF-8 URL encoded issuer DN while replacing the "%"
> with ":" in the URL encoded value, in order to support the Illegal
> characters for registry resource path (Check mail in [1]).
> Certificate Serial Num : Positive integer assigned by the CA to each
> certificate which is unique for each certificate issued by a given CA
> (i.e., the issuer name and serial number identify a unique certificate)
>
> Registry Content : *X509Certificate CA Certificate*
> Registry Properties :
> *crl - comma separated CRL URLs*
> *ocsp - comma separated OCSP URLs*
>
>- There can be certificates of Intermediate CAs and root CAs in the
>trust store (An intermediate CA is an entity that can sign certificates on
>behalf of the root CA. The root CA signs the intermediate certificate,
>forming a chain of trust). All those intermediate  and root certificates
>will be added into the registry considering following scenarios.
>
>
>1. Intermediate CAs have their own CRL and OCSP URLs
>
> Revocation of certificate is not propagated across the CA tree. Each CA
> (root and intermediate) is responsible of the publication of the CRL
> containing the list of only the revoked certificates that were issued by
> that CA and OCSP response for only the certificates that were issued by
> that CA.
>
>2. Observer intermediate CA certificates in the chain
> of trust
> For full-chain CRL/OCSP validation as mention in below, need to have
> access to intermediate CA certificates in the chain of trust to retrieve
> the CRL and OCSP Urls
>
>
> *Need of CA and intermediate CA Certificates for CRL/OCSP validation*
>
>- CRL Validation :
>   - If the CA certificate available in the registry which issued the
>   client certificate, retrieve the CRL URLs from the CA cert. If not use 
> the
>   URLs in the client certificate.
>   - In order to validate intermediate CAs when Full-chain CRL/OCSP
>   validation enabled, CRL URls will be extracted from corresponding root 
> CA.
>
>
>- OCSP Validation :
>   - For OCSP validation, CA certificate which issued the client
>   certificate should be available in the registry. Otherwise consider as a
>   unsuccessful validation.
>   - In order to validate intermediate CAs when Full-chain CRL/OCSP
>   validation enabled, OCSP URLs will be extracted from corresponding root 
> CA.
>
>
>
> *Configure Full-chain CRL/OCSP Validation *
>
> 
>
> http://wso2.org/project
> s/carbon/certificate-validation.xml">
>
> 
>
>  name="org.wso2.carbon.identity.x509Certificate.validation.validator.CRLValidator"
> displayName="CRLValidator" enable="false">
>
>   1
>
>*true*
>
>
> 
>
>  name="org.wso2.carbon.identity.x509Certificate.validation.validator.OCSPValidator"
> displayName="OCSPValidator" enable="true">
>
>   2
>
>true
>
> 
>
> 
>
> 
>
>- *Full-chain CRL/OCSP validation disabled:* validate the client
>certificate with the CRL/OCSP URLs of the issuer CA
>
>
>- *Full-chain CRL/OCSP validation enabled*: validate with the CRL/OCSP
>of every intermediate certificate within the chain of trust for the client,
>except for the root CA certificate.
>
> Ex:  Root CA (root CA CRL) Cert ==> Intermediate CA Cert(inter CA CRL) ==>
> Client Cert
> The intermediate CA CRL is used to verify whether the client certificate
> is valid. The root CA CRL is used to verify whether Intermediate CA Cert is
> valid.
>
> If Full-chain CRL/OCSP checking enabled, If the intermediate certificates
> are not available in the registry or, if a CRL is not available in any of
> the intermediate CA in the chain of trust, or the certificate is listed as
> revoke

Re: [Architecture] [bpmn] Rewrite REST API with msf4j

[Afkham Azeez]

Why don't you pass the relevant information in the HTTP payload? You can
define a Java bean that contains all the information you need to pass and
then use that as a method parameter.

On Tue, Mar 29, 2016 at 10:49 AM, Himasha Guruge  wrote:

> Hi Hasitha,
>
> Thanks for the provided suggestions. I tested the suggested approaches and
> we can go ahead with HttpRequest injection and the usage of @QueryParam.
>
>
> Regards,
> Himasha
>
> On Fri, Mar 25, 2016 at 11:02 AM, Hasitha Aravinda 
> wrote:
>
>> Hi team,
>>
>> Please find my comments inline.
>>
>> On Fri, Mar 25, 2016 at 10:27 AM, Himasha Guruge 
>> wrote:
>>
>>> Hi All,
>>>
>>> I'm in the process of rewriting our existing BPMN REST API for C5, with
>>> msf4j in place. While checking the used annotations in the code,  I came
>>> across the use of @Context annotation in order to inject UserInfo [1]
>>>  interface which provides access to application and request URI
>>> information. We have used following two methods of this interface
>>> throughout the code.
>>>
>>> (1) QueryParameters()
>>> (2) getBaseUri()
>>>
>>
>> Do we have an equlent for
>> ​
>> uriInfo.getBaseUri in MSF4J supported annotation ? Can't we use
>> io.netty.handler.codec.http.HttpRequest.getUri()
>> ​ ​
>>
>> ​?​
>>
>>
>> I tested if it's possible to inject UriInfo interface in msf4j by
>>> deploying a simple microservice sample (which uses @Context UriInfo info)
>>>  which failed with an error in executing the request, which means the
>>> injection of it is not possible with current msf4j implementation. [2]
>>>
>>> In [2] it is mentioned that there is @QueryParam annotation support in
>>> msf4j which we can use alternatively where we would have to pass the query
>>> parameter to the method in the same way we use @PathParam. See usage in [3].
>>>
>>> However, issues arise in following scenarios.
>>>
>>>  For example, In ModelService[4] we have a large  range of allowed
>>>  query params (name,nameLike,category,categoryLike etc) for a method, and
>>> based on the query params that the user has  passed (by using
>>> uriInfo.getQueryParameters()) we process the request accordingly.   In such
>>> a case if we are to use @
>>> ​​
>>> QueryParam it would mean we would have to pass all possible query
>>> parameters (Around 15) to the method.
>>>
>>
>> I think this is should be ok.
>>
>> ​
>>>
>>>
>> Also, we have used
>>> ​​
>>> uriInfo.getBaseUri() method throughout as well.
>>>
>>> How are we going to proceed with this? Appreciate your suggestions on
>>> this.
>>>
>>> [1]
>>> https://jsr311.java.net/nonav/releases/1.1/javax/ws/rs/core/UriInfo.html
>>>
>>>
>>> [2]
>>> https://docs.wso2.com/display/MSF4J100/Key+Concepts#KeyConcepts-Supportedannotations
>>>
>>> [3] http://www.mkyong.com/webservices/jax-rs/jax-rs-queryparam-example/
>>>
>>> [4]
>>> https://github.com/wso2/carbon-business-process/blob/de4d3ca5a2c3d670dcbf07ee6b58f0afd9489e95/components/bpmn/org.wso2.carbon.bpmn.rest/src/main/java/org/wso2/carbon/bpmn/rest/service/repository/ModelService.java#L98
>>>
>>> Regards,
>>>
>>> Himasha Guruge
>>> *Software Engineer*
>>> WS*O2* *Inc.*
>>> Mobile: +94 777459299
>>> himas...@wso2.com
>>>
>>
>> ​Thanks,
>> Hasitha. ​
>>
>>
>>
>>
>> --
>> --
>> Hasitha Aravinda,
>> Senior Software Engineer,
>> WSO2 Inc.
>> Email: hasi...@wso2.com
>> Mobile : +94 718 210 200
>>
>
>
>
> --
> Himasha Guruge
> *Software Engineer*
> WS*O2* *Inc.*
> Mobile: +94 777459299
> himas...@wso2.com
>



-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919blog: **http://blog.afkham.org*
<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*
<http://twitter.com/afkham_azeez>
*linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [bpmn] Rewrite REST API with msf4j

[Afkham Azeez]

One more thing, we are going to rename javax.rs.* annotations to
org.wso2.msf4j.annotations.* to avoid confusing MSF4J annotations with
JAXRS annotations.

On Tue, Mar 29, 2016 at 11:25 AM, Afkham Azeez  wrote:

> Why don't you pass the relevant information in the HTTP payload? You can
> define a Java bean that contains all the information you need to pass and
> then use that as a method parameter.
>
> On Tue, Mar 29, 2016 at 10:49 AM, Himasha Guruge 
> wrote:
>
>> Hi Hasitha,
>>
>> Thanks for the provided suggestions. I tested the suggested approaches
>> and we can go ahead with HttpRequest injection and the usage of @QueryParam.
>>
>>
>> Regards,
>> Himasha
>>
>> On Fri, Mar 25, 2016 at 11:02 AM, Hasitha Aravinda 
>> wrote:
>>
>>> Hi team,
>>>
>>> Please find my comments inline.
>>>
>>> On Fri, Mar 25, 2016 at 10:27 AM, Himasha Guruge 
>>> wrote:
>>>
>>>> Hi All,
>>>>
>>>> I'm in the process of rewriting our existing BPMN REST API for C5, with
>>>> msf4j in place. While checking the used annotations in the code,  I came
>>>> across the use of @Context annotation in order to inject UserInfo [1]
>>>>  interface which provides access to application and request URI
>>>> information. We have used following two methods of this interface
>>>> throughout the code.
>>>>
>>>> (1) QueryParameters()
>>>> (2) getBaseUri()
>>>>
>>>
>>> Do we have an equlent for
>>> ​
>>> uriInfo.getBaseUri in MSF4J supported annotation ? Can't we use
>>> io.netty.handler.codec.http.HttpRequest.getUri()
>>> ​ ​
>>>
>>> ​?​
>>>
>>>
>>> I tested if it's possible to inject UriInfo interface in msf4j by
>>>> deploying a simple microservice sample (which uses @Context UriInfo info)
>>>>  which failed with an error in executing the request, which means the
>>>> injection of it is not possible with current msf4j implementation. [2]
>>>>
>>>> In [2] it is mentioned that there is @QueryParam annotation support in
>>>> msf4j which we can use alternatively where we would have to pass the query
>>>> parameter to the method in the same way we use @PathParam. See usage in 
>>>> [3].
>>>>
>>>> However, issues arise in following scenarios.
>>>>
>>>>  For example, In ModelService[4] we have a large  range of allowed
>>>>  query params (name,nameLike,category,categoryLike etc) for a method, and
>>>> based on the query params that the user has  passed (by using
>>>> uriInfo.getQueryParameters()) we process the request accordingly.   In such
>>>> a case if we are to use @
>>>> ​​
>>>> QueryParam it would mean we would have to pass all possible query
>>>> parameters (Around 15) to the method.
>>>>
>>>
>>> I think this is should be ok.
>>>
>>> ​
>>>>
>>>>
>>> Also, we have used
>>>> ​​
>>>> uriInfo.getBaseUri() method throughout as well.
>>>>
>>>> How are we going to proceed with this? Appreciate your suggestions on
>>>> this.
>>>>
>>>> [1]
>>>> https://jsr311.java.net/nonav/releases/1.1/javax/ws/rs/core/UriInfo.html
>>>>
>>>>
>>>> [2]
>>>> https://docs.wso2.com/display/MSF4J100/Key+Concepts#KeyConcepts-Supportedannotations
>>>>
>>>> [3] http://www.mkyong.com/webservices/jax-rs/jax-rs-queryparam-example/
>>>>
>>>> [4]
>>>> https://github.com/wso2/carbon-business-process/blob/de4d3ca5a2c3d670dcbf07ee6b58f0afd9489e95/components/bpmn/org.wso2.carbon.bpmn.rest/src/main/java/org/wso2/carbon/bpmn/rest/service/repository/ModelService.java#L98
>>>>
>>>> Regards,
>>>>
>>>> Himasha Guruge
>>>> *Software Engineer*
>>>> WS*O2* *Inc.*
>>>> Mobile: +94 777459299
>>>> himas...@wso2.com
>>>>
>>>
>>> ​Thanks,
>>> Hasitha. ​
>>>
>>>
>>>
>>>
>>> --
>>> --
>>> Hasitha Aravinda,
>>> Senior Software Engineer,
>>> WSO2 Inc.
>>> Email: hasi...@wso2.com
>>> Mobile : +94 718 210 200
>>>
>>
>>
>>
>> --
>> Himasha Guruge
>> *Software Engineer*
>> WS*O2* *Inc.*
>> Mobile: +94 777459299
>> himas...@wso2.com
>>
>
>
>
> --
> *Afkham Azeez*
> Director of Architecture; WSO2, Inc.; http://wso2.com
> Member; Apache Software Foundation; http://www.apache.org/
> * <http://www.apache.org/>*
> *email: **az...@wso2.com* 
> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: *
> *http://blog.afkham.org* <http://blog.afkham.org>
> *twitter: **http://twitter.com/afkham_azeez*
> <http://twitter.com/afkham_azeez>
> *linked-in: **http://lk.linkedin.com/in/afkhamazeez
> <http://lk.linkedin.com/in/afkhamazeez>*
>
> *Lean . Enterprise . Middleware*
>



-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919blog: **http://blog.afkham.org*
<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*
<http://twitter.com/afkham_azeez>
*linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Circuit Breaker Pattern for MSF4J

[Afkham Azeez]

I have written a sample which demonstrates circuit breaker in action;
http://blog.afkham.org/2016/03/microservices-circuit-breaker.html

On Sat, Mar 12, 2016 at 6:09 PM, Afkham Azeez  wrote:

> This is a feature supported by some microservices frameworks. On the
> server side, in this case MSF4J runtime, failure counts are kept track of
> and then if the failures exceed certain thresholds, the circuit trips and
> rather than dispatch to the service, it returns service unavailable.
>
> Can you explain why this is not needed in a container environment?
>
> On Sat, Mar 12, 2016 at 12:56 PM, Sanjiva Weerawarana 
> wrote:
>
>> I don't understand what server side circuit breaker means. How does the
>> server adjust itself? Where's that bit of logic running?
>>
>> IMO this is not needed in a container world.
>>
>> On Fri, Mar 11, 2016 at 4:38 PM, Afkham Azeez  wrote:
>>
>>> Yes, that is client side circuit breaker. What Aruna is implementing is
>>> server side circuit breaker. Yes, we need both.
>>>
>>> On Fri, Mar 11, 2016 at 4:04 PM, Lakmal Warusawithana 
>>> wrote:
>>>
>>>> Did you looked at [1]
>>>>
>>>> Netflix Hystrix <https://github.com/Netflix/Hystrix> is an incredibly
>>>> useful library for writing code that invokes remote services. Hystrix times
>>>> out calls that exceed the specified threshold. It implements a *circuit
>>>> breaker* pattern, which stops the client from waiting needlessly for
>>>> an unresponsive service. If the error rate for a service exceeds a
>>>> specified threshold, Hystrix trips the circuit breaker and all requests
>>>> will fail immediately for a specified period of time. Hystrix lets you
>>>> define a fallback action when a request fails, such as reading from a cache
>>>> or returning a default value. If you are using the JVM you should
>>>> definitely consider using Hystrix.
>>>>
>>>> [1] https://github.com/Netflix/Hystrix
>>>>
>>>> On Fri, Mar 11, 2016 at 2:42 PM, Aruna Karunarathna 
>>>> wrote:
>>>>
>>>>> Hi Devs,
>>>>>
>>>>> *Scenario*
>>>>>
>>>>> The deployed services in a MSF4J may fail to serve the requests due to
>>>>> various factors. e.g,
>>>>> 1. Less resources in the server.
>>>>> 2. High Load in the server
>>>>> 3, Some services take more time to respond etc.
>>>>>
>>>>> In this kind of a situation, if the server is getting requests though
>>>>> there is no resources to serve those requests, and eventually the server
>>>>> will get unusable.
>>>>>
>>>>> *Solution*
>>>>>
>>>>> The Circuit Breaker design pattern can save the server from above
>>>>> scenarios, The typical design can be illustrated as in the following
>>>>> diagram.
>>>>>
>>>>>
>>>>> So as in the above diagram, when number of failures of a particular
>>>>> resource exceeds the Max Failure Count, then the state of that resource is
>>>>> moved to the open state with a timeout value (Trip Breaker). At this point
>>>>> the requests coming to the server is routed back without passing the
>>>>> internal to process further.
>>>>>
>>>>> After the timeout has reached, the state is moved to Half-Open state,
>>>>> and if the consecutive request pass to the server to process (Attempt
>>>>> Reset), if success then close the circuit (Reset Breaker), If fail then
>>>>> again move the state to the Open with a timeout value (Trip Breaker).
>>>>>
>>>>> Any thoughts, suggestions regarding the above approach?
>>>>>
>>>>> References
>>>>> [1].
>>>>> http://www.javaworld.com/article/2824163/application-performance/stability-patterns-applied-in-a-restful-architecture.html?page=2
>>>>> [2].
>>>>> http://ssagara.blogspot.com/2015/05/timeout-and-circuit-breaker-pattern-in.html
>>>>> [3]. https://pragprog.com/book/mnee/release-it
>>>>>
>>>>>
>>>>> Regards,
>>>>> Aruna
>>>>> --
>>>>>
>>>>> *Aruna Sujith Karunarathna *
>>>>> WSO2, Inc | lean. enterprise. middleware.
>>>>> #20, Palm Grove, Colombo 03, Sri Lanka
>>>>> Mobile: +94 71 904036

Re: [Architecture] Circuit Breaker Pattern for MSF4J

[Afkham Azeez]

Timeout is related to the actual operation taking more time than
anticipated. In such a case, without waiting indefinitely, the operation
times out and the fallback of the Hystrix command will be invoked. The
circuit will be open for a fixed period of time configured by
https://github.com/Netflix/Hystrix/wiki/Configuration#circuitBreaker.sleepWindowInMilliseconds

On Thu, Mar 31, 2016 at 2:53 AM, Harshan Liyanage  wrote:

> Hi Azeez,
>
> Does this timeout in open state occurs in exponentially (first timeout in
> 10 secs, next in 20 secs etc) or linearly when transitioning back to
> half-open state? For example if the state is in "Open" and now the timeout
> (lets say 10secs timeout) occurs. Then the state is moved to "half-open"
> state. But the next request is also a failure and breaker state is moved
> back to "open". In this occasion the what will be the timeout value? Is it
> 10 secs or 20 secs?
>
> Having an exponential timeout might be beneficiary here as it might save
> lot of resources if the service is continuously failing. But I think it
> would be better if we can provide both options in a configurable manner. So
> it is up to the developer to decide which method to use.
>
> Thanks,
>
> Harshan Liyanage
> Software Engineer
> Mobile: *+94724423048*
> Email: hars...@wso2.com
> Blog : http://harshanliyanage.blogspot.com/
> *WSO2, Inc. :** wso2.com <http://wso2.com/>*
> lean.enterprise.middleware.
>
> On Wed, Mar 30, 2016 at 5:05 AM, Afkham Azeez  wrote:
>
>> I have written a sample which demonstrates circuit breaker in action;
>> http://blog.afkham.org/2016/03/microservices-circuit-breaker.html
>>
>> On Sat, Mar 12, 2016 at 6:09 PM, Afkham Azeez  wrote:
>>
>>> This is a feature supported by some microservices frameworks. On the
>>> server side, in this case MSF4J runtime, failure counts are kept track of
>>> and then if the failures exceed certain thresholds, the circuit trips and
>>> rather than dispatch to the service, it returns service unavailable.
>>>
>>> Can you explain why this is not needed in a container environment?
>>>
>>> On Sat, Mar 12, 2016 at 12:56 PM, Sanjiva Weerawarana 
>>> wrote:
>>>
>>>> I don't understand what server side circuit breaker means. How does the
>>>> server adjust itself? Where's that bit of logic running?
>>>>
>>>> IMO this is not needed in a container world.
>>>>
>>>> On Fri, Mar 11, 2016 at 4:38 PM, Afkham Azeez  wrote:
>>>>
>>>>> Yes, that is client side circuit breaker. What Aruna is implementing
>>>>> is server side circuit breaker. Yes, we need both.
>>>>>
>>>>> On Fri, Mar 11, 2016 at 4:04 PM, Lakmal Warusawithana >>>> > wrote:
>>>>>
>>>>>> Did you looked at [1]
>>>>>>
>>>>>> Netflix Hystrix <https://github.com/Netflix/Hystrix> is an
>>>>>> incredibly useful library for writing code that invokes remote services.
>>>>>> Hystrix times out calls that exceed the specified threshold. It 
>>>>>> implements
>>>>>> a *circuit breaker* pattern, which stops the client from waiting
>>>>>> needlessly for an unresponsive service. If the error rate for a service
>>>>>> exceeds a specified threshold, Hystrix trips the circuit breaker and all
>>>>>> requests will fail immediately for a specified period of time. Hystrix 
>>>>>> lets
>>>>>> you define a fallback action when a request fails, such as reading from a
>>>>>> cache or returning a default value. If you are using the JVM you should
>>>>>> definitely consider using Hystrix.
>>>>>>
>>>>>> [1] https://github.com/Netflix/Hystrix
>>>>>>
>>>>>> On Fri, Mar 11, 2016 at 2:42 PM, Aruna Karunarathna 
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Devs,
>>>>>>>
>>>>>>> *Scenario*
>>>>>>>
>>>>>>> The deployed services in a MSF4J may fail to serve the requests due
>>>>>>> to various factors. e.g,
>>>>>>> 1. Less resources in the server.
>>>>>>> 2. High Load in the server
>>>>>>> 3, Some services take more time to respond etc.
>>>>>>>
>>>>>>> In this kind of a situation, if the server is getting requests
>>>>>>>

Re: [Architecture] Circuit Breaker Pattern for MSF4J

[Afkham Azeez]

The same concept applies to the client side as well. We could modify this
sample to show interaction between two microservices, where one service
calls the other, and if that call keeps failing, the circuit would trip,
which would be a sample for client side circuit breaker.

 In the real world, DB calls could fail for sometime (too many calls to the
DB at a given time), and there the circuit would trip and fallback to
serving from a cache, which is what this simplified example demonstrates.


On Thu, Mar 31, 2016 at 8:32 AM, Sanjiva Weerawarana 
wrote:

> So this is not what I expected the real use case to be ... this is
> basically a fancy try catch.
>
> Don't we want to show a client side example?
>
> On Thu, Mar 31, 2016 at 6:28 AM, Afkham Azeez  wrote:
>
>> Timeout is related to the actual operation taking more time than
>> anticipated. In such a case, without waiting indefinitely, the operation
>> times out and the fallback of the Hystrix command will be invoked. The
>> circuit will be open for a fixed period of time configured by
>> https://github.com/Netflix/Hystrix/wiki/Configuration#circuitBreaker.sleepWindowInMilliseconds
>>
>> On Thu, Mar 31, 2016 at 2:53 AM, Harshan Liyanage 
>> wrote:
>>
>>> Hi Azeez,
>>>
>>> Does this timeout in open state occurs in exponentially (first timeout
>>> in 10 secs, next in 20 secs etc) or linearly when transitioning back to
>>> half-open state? For example if the state is in "Open" and now the timeout
>>> (lets say 10secs timeout) occurs. Then the state is moved to "half-open"
>>> state. But the next request is also a failure and breaker state is moved
>>> back to "open". In this occasion the what will be the timeout value? Is it
>>> 10 secs or 20 secs?
>>>
>>> Having an exponential timeout might be beneficiary here as it might save
>>> lot of resources if the service is continuously failing. But I think it
>>> would be better if we can provide both options in a configurable manner. So
>>> it is up to the developer to decide which method to use.
>>>
>>> Thanks,
>>>
>>> Harshan Liyanage
>>> Software Engineer
>>> Mobile: *+94724423048*
>>> Email: hars...@wso2.com
>>> Blog : http://harshanliyanage.blogspot.com/
>>> *WSO2, Inc. :** wso2.com <http://wso2.com/>*
>>> lean.enterprise.middleware.
>>>
>>> On Wed, Mar 30, 2016 at 5:05 AM, Afkham Azeez  wrote:
>>>
>>>> I have written a sample which demonstrates circuit breaker in action;
>>>> http://blog.afkham.org/2016/03/microservices-circuit-breaker.html
>>>>
>>>> On Sat, Mar 12, 2016 at 6:09 PM, Afkham Azeez  wrote:
>>>>
>>>>> This is a feature supported by some microservices frameworks. On the
>>>>> server side, in this case MSF4J runtime, failure counts are kept track of
>>>>> and then if the failures exceed certain thresholds, the circuit trips and
>>>>> rather than dispatch to the service, it returns service unavailable.
>>>>>
>>>>> Can you explain why this is not needed in a container environment?
>>>>>
>>>>> On Sat, Mar 12, 2016 at 12:56 PM, Sanjiva Weerawarana <
>>>>> sanj...@wso2.com> wrote:
>>>>>
>>>>>> I don't understand what server side circuit breaker means. How does
>>>>>> the server adjust itself? Where's that bit of logic running?
>>>>>>
>>>>>> IMO this is not needed in a container world.
>>>>>>
>>>>>> On Fri, Mar 11, 2016 at 4:38 PM, Afkham Azeez  wrote:
>>>>>>
>>>>>>> Yes, that is client side circuit breaker. What Aruna is implementing
>>>>>>> is server side circuit breaker. Yes, we need both.
>>>>>>>
>>>>>>> On Fri, Mar 11, 2016 at 4:04 PM, Lakmal Warusawithana <
>>>>>>> lak...@wso2.com> wrote:
>>>>>>>
>>>>>>>> Did you looked at [1]
>>>>>>>>
>>>>>>>> Netflix Hystrix <https://github.com/Netflix/Hystrix> is an
>>>>>>>> incredibly useful library for writing code that invokes remote 
>>>>>>>> services.
>>>>>>>> Hystrix times out calls that exceed the specified threshold. It 
>>>>>>>> implements
>>>>>>>> a *circuit breaker* pattern, which stops the client from waiting
>>>>&

Re: [Architecture] Circuit Breaker Pattern for MSF4J

[Afkham Azeez]

Equating these fault tolerance patterns to Java 8 Optional or try-catch, is
a highly oversimplified view. What Hystrix and these patterns provides is a
framework for building fault tolerant systems. Something that is useful in
the toolkit of an architect & developer.

On Thu, Mar 31, 2016 at 8:36 AM, Sanjiva Weerawarana 
wrote:

> This is almost kinda like that stupid new Java8 thing of "we removed null
> by wrapping it in a fancy object" ;-).
>
> On Thu, Mar 31, 2016 at 8:32 AM, Sanjiva Weerawarana 
> wrote:
>
>> So this is not what I expected the real use case to be ... this is
>> basically a fancy try catch.
>>
>> Don't we want to show a client side example?
>>
>> On Thu, Mar 31, 2016 at 6:28 AM, Afkham Azeez  wrote:
>>
>>> Timeout is related to the actual operation taking more time than
>>> anticipated. In such a case, without waiting indefinitely, the operation
>>> times out and the fallback of the Hystrix command will be invoked. The
>>> circuit will be open for a fixed period of time configured by
>>> https://github.com/Netflix/Hystrix/wiki/Configuration#circuitBreaker.sleepWindowInMilliseconds
>>>
>>> On Thu, Mar 31, 2016 at 2:53 AM, Harshan Liyanage 
>>> wrote:
>>>
>>>> Hi Azeez,
>>>>
>>>> Does this timeout in open state occurs in exponentially (first timeout
>>>> in 10 secs, next in 20 secs etc) or linearly when transitioning back to
>>>> half-open state? For example if the state is in "Open" and now the timeout
>>>> (lets say 10secs timeout) occurs. Then the state is moved to "half-open"
>>>> state. But the next request is also a failure and breaker state is moved
>>>> back to "open". In this occasion the what will be the timeout value? Is it
>>>> 10 secs or 20 secs?
>>>>
>>>> Having an exponential timeout might be beneficiary here as it might
>>>> save lot of resources if the service is continuously failing. But I think
>>>> it would be better if we can provide both options in a configurable manner.
>>>> So it is up to the developer to decide which method to use.
>>>>
>>>> Thanks,
>>>>
>>>> Harshan Liyanage
>>>> Software Engineer
>>>> Mobile: *+94724423048*
>>>> Email: hars...@wso2.com
>>>> Blog : http://harshanliyanage.blogspot.com/
>>>> *WSO2, Inc. :** wso2.com <http://wso2.com/>*
>>>> lean.enterprise.middleware.
>>>>
>>>> On Wed, Mar 30, 2016 at 5:05 AM, Afkham Azeez  wrote:
>>>>
>>>>> I have written a sample which demonstrates circuit breaker in action;
>>>>> http://blog.afkham.org/2016/03/microservices-circuit-breaker.html
>>>>>
>>>>> On Sat, Mar 12, 2016 at 6:09 PM, Afkham Azeez  wrote:
>>>>>
>>>>>> This is a feature supported by some microservices frameworks. On the
>>>>>> server side, in this case MSF4J runtime, failure counts are kept track of
>>>>>> and then if the failures exceed certain thresholds, the circuit trips and
>>>>>> rather than dispatch to the service, it returns service unavailable.
>>>>>>
>>>>>> Can you explain why this is not needed in a container environment?
>>>>>>
>>>>>> On Sat, Mar 12, 2016 at 12:56 PM, Sanjiva Weerawarana <
>>>>>> sanj...@wso2.com> wrote:
>>>>>>
>>>>>>> I don't understand what server side circuit breaker means. How does
>>>>>>> the server adjust itself? Where's that bit of logic running?
>>>>>>>
>>>>>>> IMO this is not needed in a container world.
>>>>>>>
>>>>>>> On Fri, Mar 11, 2016 at 4:38 PM, Afkham Azeez 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Yes, that is client side circuit breaker. What Aruna is
>>>>>>>> implementing is server side circuit breaker. Yes, we need both.
>>>>>>>>
>>>>>>>> On Fri, Mar 11, 2016 at 4:04 PM, Lakmal Warusawithana <
>>>>>>>> lak...@wso2.com> wrote:
>>>>>>>>
>>>>>>>>> Did you looked at [1]
>>>>>>>>>
>>>>>>>>> Netflix Hystrix <https://github.com/Netflix/Hystrix> is an
>>>>>>>>> incredibly useful library for writing code 

Re: [Architecture] Circuit Breaker Pattern for MSF4J

[Afkham Azeez]

On Thu, Mar 31, 2016 at 9:04 AM, Sanjiva Weerawarana 
wrote:

> That's why I said "fancy try catch" :-).
>
> However, are you SERIOUSLY saying that we for example should be wrapping
> all our DB access code in this stuff? If not who exactly should be doing
> this? What are the perf implications?
>

No I am not saying that. However, there will be use cases where people want
to use this pattern and this is a simplified sample that demonstrates how
to use this pattern. In Nygards book about how an SQL statement execution
failure resulted in an entire checking in system in an airline failing
because the failure propagated is a good example of uncontrolled failure
propagation (Release It, Chapter 2: Case study: The exception that grounded
an airline, for those of you who have the book). So my example was somewhat
inspired by that case study and is highly simplified.

If a sample is too complicated, people get lost in the implementation
details rather than seeing how the core concept or pattern is implemented.
I certainly can implement another sample which demonstrates client->service
or service->service calls, it certainly would add more code but the core
concept demonstrated would be the same.



>
> Of course wrapping remote service calls in this stuff makes sense - great
> way to adjust to transient issues. In that case the overhead is heavily
> masked by the latency - I'm not so convinced that is the case for
> transactional JDBC calls but maybe it is. In that case WE must use it
> internally.
>
> Sanjiva.
>
> On Thu, Mar 31, 2016 at 8:53 AM, Afkham Azeez  wrote:
>
>> Equating these fault tolerance patterns to Java 8 Optional or try-catch,
>> is a highly oversimplified view. What Hystrix and these patterns provides
>> is a framework for building fault tolerant systems. Something that is
>> useful in the toolkit of an architect & developer.
>>
>> On Thu, Mar 31, 2016 at 8:36 AM, Sanjiva Weerawarana 
>> wrote:
>>
>>> This is almost kinda like that stupid new Java8 thing of "we removed
>>> null by wrapping it in a fancy object" ;-).
>>>
>>> On Thu, Mar 31, 2016 at 8:32 AM, Sanjiva Weerawarana 
>>> wrote:
>>>
>>>> So this is not what I expected the real use case to be ... this is
>>>> basically a fancy try catch.
>>>>
>>>> Don't we want to show a client side example?
>>>>
>>>> On Thu, Mar 31, 2016 at 6:28 AM, Afkham Azeez  wrote:
>>>>
>>>>> Timeout is related to the actual operation taking more time than
>>>>> anticipated. In such a case, without waiting indefinitely, the operation
>>>>> times out and the fallback of the Hystrix command will be invoked. The
>>>>> circuit will be open for a fixed period of time configured by
>>>>> https://github.com/Netflix/Hystrix/wiki/Configuration#circuitBreaker.sleepWindowInMilliseconds
>>>>>
>>>>> On Thu, Mar 31, 2016 at 2:53 AM, Harshan Liyanage 
>>>>> wrote:
>>>>>
>>>>>> Hi Azeez,
>>>>>>
>>>>>> Does this timeout in open state occurs in exponentially (first
>>>>>> timeout in 10 secs, next in 20 secs etc) or linearly when transitioning
>>>>>> back to half-open state? For example if the state is in "Open" and now 
>>>>>> the
>>>>>> timeout (lets say 10secs timeout) occurs. Then the state is moved to
>>>>>> "half-open" state. But the next request is also a failure and breaker 
>>>>>> state
>>>>>> is moved back to "open". In this occasion the what will be the timeout
>>>>>> value? Is it 10 secs or 20 secs?
>>>>>>
>>>>>> Having an exponential timeout might be beneficiary here as it might
>>>>>> save lot of resources if the service is continuously failing. But I think
>>>>>> it would be better if we can provide both options in a configurable 
>>>>>> manner.
>>>>>> So it is up to the developer to decide which method to use.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Harshan Liyanage
>>>>>> Software Engineer
>>>>>> Mobile: *+94724423048*
>>>>>> Email: hars...@wso2.com
>>>>>> Blog : http://harshanliyanage.blogspot.com/
>>>>>> *WSO2, Inc. :** wso2.com <http://wso2.com/>*
>>>>>> lean.enterprise.middleware.
>>>>>>
>>>>>> On Wed, Mar 

Re: [Architecture] Supporting Carbon Metrics on Carbon 5 based products

[Afkham Azeez]

> will happen to that in Carbon 5?
>>>> >> >> >
>>>> >> >> > How can we implement REST services in Carbon 5? (We may not
>>>> need this
>>>> >> >> > if
>>>> >> >> > we
>>>> >> >> > are not developing any UIs)
>>>> >> >> >
>>>> >> >> > By default, Metrics data are stored in local H2 database. Can
>>>> we use
>>>> >> >> > the
>>>> >> >> > same approach in Carbon 5? (This is not needed if we stop using
>>>> the
>>>> >> >> > JDBC
>>>> >> >> > reporter).
>>>> >> >> >
>>>> >> >> > There is also a properties file to configure Metric Levels. I
>>>> hope
>>>> >> >> > that's
>>>> >> >> > not a problem.
>>>> >> >> >
>>>> >> >> > The plan is to use v2.0.0 for Metrics release with Carbon 5. We
>>>> can
>>>> >> >> > maintain
>>>> >> >> > v1.x.x branch for Carbon 4.x.x products.
>>>> >> >> >
>>>> >> >> > Currently the WSO2 Gateway and MSF4J uses Carbon Metrics as
>>>> Maven
>>>> >> >> > Dependencies. We need a proper Carbon 5 supported release to
>>>> >> >> > integrate
>>>> >> >> > Carbon Metrics to these products.
>>>> >> >> >
>>>> >> >> > I really appreciate your feedback on this.
>>>> >> >> >
>>>> >> >> > Thanks!
>>>> >> >> >
>>>> >> >> > Best Regards,
>>>> >> >> >
>>>> >> >> > --
>>>> >> >> > Isuru Perera
>>>> >> >> > Associate Technical Lead | WSO2, Inc. | http://wso2.com/
>>>> >> >> > Lean . Enterprise . Middleware
>>>> >> >> >
>>>> >> >> > about.me/chrishantha
>>>> >> >> > Contact: +IsuruPereraWSO2
>>>> >> >>
>>>> >> >>
>>>> >> >>
>>>> >> >> --
>>>> >> >> Ramith Jayasinghe
>>>> >> >> Technical Lead
>>>> >> >> WSO2 Inc., http://wso2.com
>>>> >> >> lean.enterprise.middleware
>>>> >> >>
>>>> >> >> E: ram...@wso2.com
>>>> >> >> P: +94 777542851
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > --
>>>> >> > S. Suhothayan
>>>> >> > Technical Lead & Team Lead of WSO2 Complex Event Processor
>>>> >> > WSO2 Inc. http://wso2.com
>>>> >> > lean . enterprise . middleware
>>>> >> >
>>>> >> > cell: (+94) 779 756 757 | blog: http://suhothayan.blogspot.com/
>>>> >> > twitter: http://twitter.com/suhothayan | linked-in:
>>>> >> > http://lk.linkedin.com/in/suhothayan
>>>> >>
>>>> >>
>>>> >>
>>>> >> --
>>>> >> Ramith Jayasinghe
>>>> >> Technical Lead
>>>> >> WSO2 Inc., http://wso2.com
>>>> >> lean.enterprise.middleware
>>>> >>
>>>> >> E: ram...@wso2.com
>>>> >> P: +94 777542851
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > S. Suhothayan
>>>> > Technical Lead & Team Lead of WSO2 Complex Event Processor
>>>> > WSO2 Inc. http://wso2.com
>>>> > lean . enterprise . middleware
>>>> >
>>>> > cell: (+94) 779 756 757 | blog: http://suhothayan.blogspot.com/
>>>> > twitter: http://twitter.com/suhothayan | linked-in:
>>>> > http://lk.linkedin.com/in/suhothayan
>>>>
>>>>
>>>>
>>>> --
>>>> Ramith Jayasinghe
>>>> Technical Lead
>>>> WSO2 Inc., http://wso2.com
>>>> lean.enterprise.middleware
>>>>
>>>> E: ram...@wso2.com
>>>> P: +94 777542851
>>>>
>>>
>>>
>>>
>>> --
>>> Isuru Perera
>>> Associate Technical Lead | WSO2, Inc. | http://wso2.com/
>>> Lean . Enterprise . Middleware
>>>
>>> about.me/chrishantha
>>> Contact: +IsuruPereraWSO2
>>> <https://www.google.com/+IsuruPereraWSO2/about>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> *Kishanthan Thangarajah*
>> Associate Technical Lead,
>> Platform Technologies Team,
>> WSO2, Inc.
>> lean.enterprise.middleware
>>
>> Mobile - +94773426635
>> Blog - *http://kishanthan.wordpress.com
>> <http://kishanthan.wordpress.com>*
>> Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>*
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Isuru Perera
> Associate Technical Lead | WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> about.me/chrishantha
> Contact: +IsuruPereraWSO2 <https://www.google.com/+IsuruPereraWSO2/about>
>



-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919blog: **http://blog.afkham.org*
<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*
<http://twitter.com/afkham_azeez>
*linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Circuit Breaker Pattern for MSF4J

[Afkham Azeez]

On Thu, Mar 31, 2016 at 5:03 PM, Frank Leymann  wrote:

> Yes, all the stability patterns (that Nygard describes, the circuit
> breaker being just one of them)
> is not associated with microservices, but applies to all distributed
> applications. In fact, Nygard's
> book has been published in 2007, lng before the microservice
> discussion came up ;-)
>
> Yes Frank, agreed. With the hype about microservices, people have started
talking about these a lot and during the evaluation phase, people look at
features available in frameworks. I don't understand the excitement here.
We are not saying CircuitBreaker etc have to be used. That is as stupid as
saying every object instantiation has to be done via a Factory.


> Applying these patterns to each and any invocation would be a complete
> misuse.
>

Yes, it would very stupid for someone to design a system like that or to
suggest something like that, like I said it would be like asking to
instantiate all objects using the Factory pattern!

Patterns are just part of the toolkit of architects & developers. Knowing
to use the appropriate one at the appropriate place requires proper
judgment. This sample nor this mail thread is not suggesting to use these
everywhere, and I don't understand what gave the impression that we are
suggesting such a thing.


> And it will very likely
> result in performance hits...  The circuit breaker pattern, for example,
> is recommended to be applied
> to "out-of-spec errors", i.e. errors that you don't cover in the spec
> (because the errors are too unlikely ;-))
> of the invoked function or in the spec of the program making the call (aka
> client). Often, these are errors
> that never happen during testing unless you really set up a badly behaving
> test environment. And it has
> impact on the design/implementation of the circuit breaker itself (or
> clients), for example "critical work"
> not accepted by the circuit breaker has be queued (by the client? by the
> circuit breaker?) for later use
> (automatic replay?).
>
> Thus, using one of the stability patterns is a (architecture/design)
> decision with implications on other
> components architecture/design.
>
> Documenting a sample use of the circuit breaker pattern should also
> discuss these ramifications.
>
>
Thanks. We will include these recommendations in our documentation.


>
> Best regards,
> Frank
>
> 2016-03-31 9:12 GMT+02:00 Sanjiva Weerawarana :
>
>> Agreed. However I had understood that the circuit breaker pattern was
>> advocated primarily for service clients in MSA (and of course it has
>> nothing do with being micro).
>>
>> The general story of better failure handling applies to all code and is
>> of course not MSA specific.
>>
>> Anyway .. Sample is fine.
>> On Mar 31, 2016 9:19 AM, "Afkham Azeez"  wrote:
>>
>>>
>>>
>>> On Thu, Mar 31, 2016 at 9:04 AM, Sanjiva Weerawarana 
>>> wrote:
>>>
>>>> That's why I said "fancy try catch" :-).
>>>>
>>>> However, are you SERIOUSLY saying that we for example should be
>>>> wrapping all our DB access code in this stuff? If not who exactly should be
>>>> doing this? What are the perf implications?
>>>>
>>>
>>> No I am not saying that. However, there will be use cases where people
>>> want to use this pattern and this is a simplified sample that demonstrates
>>> how to use this pattern. In Nygards book about how an SQL statement
>>> execution failure resulted in an entire checking in system in an airline
>>> failing because the failure propagated is a good example of uncontrolled
>>> failure propagation (Release It, Chapter 2: Case study: The exception that
>>> grounded an airline, for those of you who have the book). So my example was
>>> somewhat inspired by that case study and is highly simplified.
>>>
>>> If a sample is too complicated, people get lost in the implementation
>>> details rather than seeing how the core concept or pattern is implemented.
>>> I certainly can implement another sample which demonstrates client->service
>>> or service->service calls, it certainly would add more code but the core
>>> concept demonstrated would be the same.
>>>
>>>
>>>
>>>>
>>>> Of course wrapping remote service calls in this stuff makes sense -
>>>> great way to adjust to transient issues. In that case the overhead is
>>>> heavily masked by the latency - I'm not so convinced that is the case for
>>>> transactional JDBC calls but maybe

Re: [Architecture] Circuit Breaker Pattern for MSF4J

[Afkham Azeez]

The blog post has been removed. Sorry for all the confusion. This was only
done as part of the agreement we had during last week's meeting to
demonstrate certain features such as Spring support, JPA support, support
for patterns etc. in order to help developers understand how to implement
certain stuff with MSF4J. Our target community of MSF4J is primarily
developers, and developers like to refer to sample code segments in order
to proceed with implementing their solutions. We lazy developers love to
Google search for code segments, e.g. JDBC connection example, and then
copy, paste and modify those segments. What I have been trying to do with
the series of blogposts is to make available such code segments developers
could readily use. Since this post and mail thread has generated a lot of
negative feeling and confusion, I think it is better to get rid of this
controversial blog post.

Thanks
Azeez

On Thu, Mar 31, 2016 at 6:54 PM, Afkham Azeez  wrote:

>
>
> On Thu, Mar 31, 2016 at 5:03 PM, Frank Leymann  wrote:
>
>> Yes, all the stability patterns (that Nygard describes, the circuit
>> breaker being just one of them)
>> is not associated with microservices, but applies to all distributed
>> applications. In fact, Nygard's
>> book has been published in 2007, lng before the microservice
>> discussion came up ;-)
>>
>> Yes Frank, agreed. With the hype about microservices, people have started
> talking about these a lot and during the evaluation phase, people look at
> features available in frameworks. I don't understand the excitement here.
> We are not saying CircuitBreaker etc have to be used. That is as stupid as
> saying every object instantiation has to be done via a Factory.
>
>
>> Applying these patterns to each and any invocation would be a complete
>> misuse.
>>
>
> Yes, it would very stupid for someone to design a system like that or to
> suggest something like that, like I said it would be like asking to
> instantiate all objects using the Factory pattern!
>
> Patterns are just part of the toolkit of architects & developers. Knowing
> to use the appropriate one at the appropriate place requires proper
> judgment. This sample nor this mail thread is not suggesting to use these
> everywhere, and I don't understand what gave the impression that we are
> suggesting such a thing.
>
>
>> And it will very likely
>> result in performance hits...  The circuit breaker pattern, for example,
>> is recommended to be applied
>> to "out-of-spec errors", i.e. errors that you don't cover in the spec
>> (because the errors are too unlikely ;-))
>> of the invoked function or in the spec of the program making the call
>> (aka client). Often, these are errors
>> that never happen during testing unless you really set up a badly
>> behaving test environment. And it has
>> impact on the design/implementation of the circuit breaker itself (or
>> clients), for example "critical work"
>> not accepted by the circuit breaker has be queued (by the client? by the
>> circuit breaker?) for later use
>> (automatic replay?).
>>
>> Thus, using one of the stability patterns is a (architecture/design)
>> decision with implications on other
>> components architecture/design.
>>
>> Documenting a sample use of the circuit breaker pattern should also
>> discuss these ramifications.
>>
>>
> Thanks. We will include these recommendations in our documentation.
>
>
>>
>> Best regards,
>> Frank
>>
>> 2016-03-31 9:12 GMT+02:00 Sanjiva Weerawarana :
>>
>>> Agreed. However I had understood that the circuit breaker pattern was
>>> advocated primarily for service clients in MSA (and of course it has
>>> nothing do with being micro).
>>>
>>> The general story of better failure handling applies to all code and is
>>> of course not MSA specific.
>>>
>>> Anyway .. Sample is fine.
>>> On Mar 31, 2016 9:19 AM, "Afkham Azeez"  wrote:
>>>
>>>>
>>>>
>>>> On Thu, Mar 31, 2016 at 9:04 AM, Sanjiva Weerawarana 
>>>> wrote:
>>>>
>>>>> That's why I said "fancy try catch" :-).
>>>>>
>>>>> However, are you SERIOUSLY saying that we for example should be
>>>>> wrapping all our DB access code in this stuff? If not who exactly should 
>>>>> be
>>>>> doing this? What are the perf implications?
>>>>>
>>>>
>>>> No I am not saying that. However, there will be use cases where people
>>>> want to use

Re: [Architecture] Circuit Breaker Pattern for MSF4J

[Afkham Azeez]

Well one of your responses indicated that the the blogpost suggests
wrapping all DB calls in circuit breakers, and Frank's response indicated
that it is suggesting wrapping all calls to external systems in circuit
breakers.  If it can confuse such brilliant minds, I guess it could mislead
an average developer. That blogpost was on how to implement the pattern in
the context of MSF4J using Hystrix, and I think it should have been
preceded with a blogpost introducing the pattern & explaining where it is
applicable. Sorry for the confusion again. I will work on a separate post.

Thanks
Azeez

On Fri, Apr 1, 2016 at 11:59 PM, Sanjiva Weerawarana 
wrote:

> Azeez, asking questions and asking to understand what the purpose of some
> code is not a criticism.
>
> Of course there should be a sample! I only asked about it because to me a
> client side sample made more sense - and then it went into a discussion of
> when this should be used etc..
>
> I would not only put the blog back but also use the opportunity to explain
> to "lazy developers" when and where one should use a circuitbreaker. That's
> 1000x more valuable than just the code on how to do it.
>
> Sanjiva.
>
> On Thu, Mar 31, 2016 at 8:00 PM, Afkham Azeez  wrote:
>
>> The blog post has been removed. Sorry for all the confusion. This was
>> only done as part of the agreement we had during last week's meeting to
>> demonstrate certain features such as Spring support, JPA support, support
>> for patterns etc. in order to help developers understand how to implement
>> certain stuff with MSF4J. Our target community of MSF4J is primarily
>> developers, and developers like to refer to sample code segments in order
>> to proceed with implementing their solutions. We lazy developers love to
>> Google search for code segments, e.g. JDBC connection example, and then
>> copy, paste and modify those segments. What I have been trying to do with
>> the series of blogposts is to make available such code segments developers
>> could readily use. Since this post and mail thread has generated a lot of
>> negative feeling and confusion, I think it is better to get rid of this
>> controversial blog post.
>>
>> Thanks
>> Azeez
>>
>> On Thu, Mar 31, 2016 at 6:54 PM, Afkham Azeez  wrote:
>>
>>>
>>>
>>> On Thu, Mar 31, 2016 at 5:03 PM, Frank Leymann  wrote:
>>>
>>>> Yes, all the stability patterns (that Nygard describes, the circuit
>>>> breaker being just one of them)
>>>> is not associated with microservices, but applies to all distributed
>>>> applications. In fact, Nygard's
>>>> book has been published in 2007, lng before the microservice
>>>> discussion came up ;-)
>>>>
>>>> Yes Frank, agreed. With the hype about microservices, people have
>>> started talking about these a lot and during the evaluation phase, people
>>> look at features available in frameworks. I don't understand the excitement
>>> here. We are not saying CircuitBreaker etc have to be used. That is as
>>> stupid as saying every object instantiation has to be done via a Factory.
>>>
>>>
>>>> Applying these patterns to each and any invocation would be a complete
>>>> misuse.
>>>>
>>>
>>> Yes, it would very stupid for someone to design a system like that or to
>>> suggest something like that, like I said it would be like asking to
>>> instantiate all objects using the Factory pattern!
>>>
>>> Patterns are just part of the toolkit of architects & developers.
>>> Knowing to use the appropriate one at the appropriate place requires proper
>>> judgment. This sample nor this mail thread is not suggesting to use these
>>> everywhere, and I don't understand what gave the impression that we are
>>> suggesting such a thing.
>>>
>>>
>>>> And it will very likely
>>>> result in performance hits...  The circuit breaker pattern, for
>>>> example, is recommended to be applied
>>>> to "out-of-spec errors", i.e. errors that you don't cover in the spec
>>>> (because the errors are too unlikely ;-))
>>>> of the invoked function or in the spec of the program making the call
>>>> (aka client). Often, these are errors
>>>> that never happen during testing unless you really set up a badly
>>>> behaving test environment. And it has
>>>> impact on the design/implementation of the circuit breaker itself (or
>>>> clients), for example "critical work&q

Re: [Architecture] Circuit Breaker Pattern for MSF4J

[Afkham Azeez]

On Sun, Apr 3, 2016 at 6:48 AM, Sanjiva Weerawarana 
wrote:

> :-). I think there are two things we should show:
> - one can do circuit breaker (CB) with MSF4J
> - when should you use it
>
> Wrapping of DB calls in Hystrix may indeed be appropriate in some cases,
> but not commonly. Second, at that level its really not about MSF4J at all.
>

Yes, that is correct, MSF4J after all is just a Java library, but people
ask how to do do xyz with MSF4J. So in my recent blogposts, I have been
trying to make it easy for people to find the answers through Googling for
some of the questions I have received from people whom I have spoken to.

http://techblog.netflix.com/2011/12/making-netflix-api-more-resilient.html
is a good read, and for one of the use cases, they wrap a DB select query
in a circuit breaker since if that fails, it is possible to fallback to the
cache.


>
> If we show a sample that's a service invoking another service or some
> random Java code invoking a service using CB then that's better IMO. We
> should mention when it is indeed appropriate to use as a fancy try catch.
>
> For example, in the registry code we have scenarios where there can be
> transient DB issues because of concurrent access. Should we use CB there to
> make that code more resilient? Almost always the transaction "failure" in
> those cases is a temporary issue and a non-issue ... just bad timing.
>

For transient issues, the common way to try to recover is retrying, and
after a few retries (we can use binary backoff with timeout), it could be
possible to have some sort of fallback, perhaps send a notification about
the failure & serve from a cache until it times out.


>
> If we can make our code better with CB we absolutely MUST do it. The key
> is to provide guidance on when its appropriate to do it!
>

Yes, agreed.

>
> Sanjiva.
>
> On Sat, Apr 2, 2016 at 8:24 AM, Afkham Azeez  wrote:
>
>> Well one of your responses indicated that the the blogpost suggests
>> wrapping all DB calls in circuit breakers, and Frank's response indicated
>> that it is suggesting wrapping all calls to external systems in circuit
>> breakers.  If it can confuse such brilliant minds, I guess it could mislead
>> an average developer. That blogpost was on how to implement the pattern in
>> the context of MSF4J using Hystrix, and I think it should have been
>> preceded with a blogpost introducing the pattern & explaining where it is
>> applicable. Sorry for the confusion again. I will work on a separate post.
>>
>> Thanks
>> Azeez
>>
>> On Fri, Apr 1, 2016 at 11:59 PM, Sanjiva Weerawarana 
>> wrote:
>>
>>> Azeez, asking questions and asking to understand what the purpose of
>>> some code is not a criticism.
>>>
>>> Of course there should be a sample! I only asked about it because to me
>>> a client side sample made more sense - and then it went into a discussion
>>> of when this should be used etc..
>>>
>>> I would not only put the blog back but also use the opportunity to
>>> explain to "lazy developers" when and where one should use a
>>> circuitbreaker. That's 1000x more valuable than just the code on how to do
>>> it.
>>>
>>> Sanjiva.
>>>
>>> On Thu, Mar 31, 2016 at 8:00 PM, Afkham Azeez  wrote:
>>>
>>>> The blog post has been removed. Sorry for all the confusion. This was
>>>> only done as part of the agreement we had during last week's meeting to
>>>> demonstrate certain features such as Spring support, JPA support, support
>>>> for patterns etc. in order to help developers understand how to implement
>>>> certain stuff with MSF4J. Our target community of MSF4J is primarily
>>>> developers, and developers like to refer to sample code segments in order
>>>> to proceed with implementing their solutions. We lazy developers love to
>>>> Google search for code segments, e.g. JDBC connection example, and then
>>>> copy, paste and modify those segments. What I have been trying to do with
>>>> the series of blogposts is to make available such code segments developers
>>>> could readily use. Since this post and mail thread has generated a lot of
>>>> negative feeling and confusion, I think it is better to get rid of this
>>>> controversial blog post.
>>>>
>>>> Thanks
>>>> Azeez
>>>>
>>>> On Thu, Mar 31, 2016 at 6:54 PM, Afkham Azeez  wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Mar 31, 2016 at 5:03 PM, Frank Leymann  wrote:
>>>

Re: [Architecture] [AppCloud] Publishing AppCloud specific data from MSF4J and AS HTTP Monitoring Data Publishers

[Afkham Azeez]

Yes, looks like "arbitrary" is a concept in DAS but it doesn't make sense
to name env vars like that.

On Mon, Apr 4, 2016 at 2:59 PM, Kalpa Welivitigoda  wrote:

> Hi Pirinthapan,
>
> As per the offline chat we had, this is being implemented and tracked with
> [1]. About the prefix, how about we using "WSO2_" as the prefix.
> WSO2_TENANT_ID seems to make more sense. WDYT?
>
> [1] https://wso2.org/jira/browse/WSAS-2225
>
> On Mon, Apr 4, 2016 at 1:17 PM, Pirinthapan Mahendran <
> pirintha...@wso2.com> wrote:
>
>> Hi all,
>>
>> In AppCloud we will be having the HTTP Monitoring dashboards to showing
>> the statistics of the application usages. To accomplish this, we will be
>> using the data publishers shiped with msf4j and AS-6.0.0. But still we need
>> to publish some AppCloud specific data (i.e : Application Name, Application
>> Version, etc.)  and tenant id from these publishers to DAS.
>>
>> To publish these custom data we have come with the following solution,
>> which requires some modification in the msf4j and AS publishers.
>>
>> *When creating the containers during the application deployment, AppCloud
>> will set these custom data as Environment Variables. These environment
>> variables are prefixed with the keyword 'arbitrary'. *
>>
>> *e.g : If we are setting application name as an environment variable, the
>> key of this environment variable will looks like
>> 'arbitrary_applicationName'.*
>>
>> *Then during the publishing time, the msf4j or AS will read all the
>> environment variables with the prefix 'arbitrary' and publish them as
>> arbitrary attributes to DAS.*
>>
>> *The stream definition in the DAS will be configured to capture these
>> arbitrary attributes and use them for its internal processing.*
>>
>> In order to implement this solution we are planning to add these changes
>> to the next releases of msf4j and AS with the coordination of msf4j and As
>> teams.
>>
>> If you have any comments on the above solution, we are kindly
>> appreciating them.
>>
>> Thanks & Regards,
>> Mahendran Pirinthapan
>> Software Engineer | WSO2 Inc.
>> Mobile +94772378732.
>>
>
>
>
> --
> Best Regards,
>
> Kalpa Welivitigoda
> Software Engineer, WSO2 Inc. http://wso2.com
> Email: kal...@wso2.com
> Mobile: +94776509215
>



-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919blog: **http://blog.afkham.org*
<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*
<http://twitter.com/afkham_azeez>
*linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Supporting Carbon Metrics on Carbon 5 based products

[Afkham Azeez]

Name is ok. Yes, I think for advanced metrics config stuff, we will need to
provide a file.

On Thu, Apr 7, 2016 at 2:02 PM, Isuru Perera  wrote:

> Hi Azeez,
>
> How about carbon-metrics-extensions for new repo name? This new repo will
> have the MSF4J REST API to get data from JDBC.
>
> I have another question regarding JDBC Reporter. Since all reporters are
> now a part of metrics core, the JDBC reporter will also be available for
> MSF4J. Earlier, MSF4J supported only Console, JMX and DAS reporters. In a
> future MSF4J version, when metrics wants to use the JDBC reporter we need
> to figure out a way to initialize the JDBC Data Source.
>
> In OSGi environment, I'm planning to use carbon-datasources [1]. However
> we cannot use that in MSF4J. We need to be able to directly configure a
> datasource for metrics. So, I thought of giving an option to initialize a
> HikariCP [2] datasource directly from metrics. I can use a properties file
> to configure HikariCP [3]. (I chose HikariCP as it's already used in
> carbon-datasources).
>
> This means, when MSF4J wants to use JDBC Reporter, we need following
> config files.
>
>- metrics.yml (To enable Metrics and JDBC Reporter)
>- metrics-datasource.properties (To configure HikariCP datasource)
>
> WDYT?
>
> Thanks!
>
> Best Regards,
> [1] https://github.com/wso2/carbon-datasources
> [2] http://brettwooldridge.github.io/HikariCP/
> [3] https://github.com/brettwooldridge/HikariCP#initialization
>
>
> On Thu, Mar 31, 2016 at 11:54 AM, Isuru Perera  wrote:
>
>> Hi Azeez,
>>
>> I meant the same thing as you. I should have explained it more clearly. :)
>>
>> So, I'll break metrics into 2 repositories. One repository will be having
>> the core Metrics features, which *will be used* by MSF4J.
>>
>> Other metrics related repository will have the REST API, written with
>> MSF4J. So, it depends on MSF4J. (I'm thinking of a name for the new repo)
>>
>> Thanks!
>>
>> Best Regards,
>>
>>
>> On Thu, Mar 31, 2016 at 11:17 AM, Afkham Azeez  wrote:
>>
>>>
>>>
>>> On Thu, Mar 31, 2016 at 11:03 AM, Isuru Perera  wrote:
>>>
>>>> Hi,
>>>>
>>>> I have another question.
>>>>
>>>> The MSF4J depends on Metrics and now Metrics needs MSF4J to implement
>>>> REST services. So, there is a cyclic dependency. I think it's wrong that
>>>> carbon-metrics repo [1] depending on msf4j repo [2].
>>>>
>>>> One solution to this is to have separate repos for metrics.
>>>>
>>>> One repo will include only the metrics core features and it'll not
>>>> depend on the MSF4J. Then MSF4J can depend on metrics core. We can create
>>>> another repository to keep the REST services and gadgets to view the
>>>> metrics.
>>>>
>>>
>>> We are targeting MSF4J at external developers. Unlike our other
>>> components & products, if the relevant code is in several places, it could
>>> become cumbersome for external developers. I think what should be done is
>>> have metrics-core, on which MSF4J depends, and then have metrics REST
>>> services somewhere else. That can take a dependency on both metrics-core
>>> and MSF4J.
>>>
>>>
>>>>
>>>> WDYT?
>>>>
>>>> Thanks!
>>>>
>>>> Best Regards,
>>>>
>>>> [1] https://github.com/wso2/carbon-metrics
>>>> [2] https://github.com/wso2/msf4j
>>>>
>>>> On Thu, Mar 17, 2016 at 10:53 PM, Kishanthan Thangarajah <
>>>> kishant...@wso2.com> wrote:
>>>>
>>>>> Like with generic HTTP Monitoring Dashboard (gadgets), we could have
>>>>> generic gadgets for Metrics here so that products can reuse them with the
>>>>> analytics dashboard.
>>>>>
>>>>> I think you can do a carbon 5 based release of the metrics
>>>>> dependencies (a carbon feature release) and also expose those services 
>>>>> used
>>>>> with metrics data fetching as microservices as you mentioned.
>>>>>
>>>>> On Mon, Mar 14, 2016 at 5:01 PM, Isuru Perera  wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> Thanks for the feedback. So, we agree that the Carbon Metrics should
>>>>>> continue supporting JDBC reporter and visualize the Metrics via gadgets.
>>>>>>
>>>>>> With Carbon

Re: [Architecture] [C5] Carbon Permission Model - Meeting Notes

[Afkham Azeez]

Model 2 is basically saying every operation has to be represented as a
resource and then use resource permissions. IMO, that is not a very good
model because representing every operation as a resource is not natural. In
addition, if you take Java Security, they have a model for securing code
blocks. That is at the lowest level, IMO. At the next level, I think we
need a model to specify who can do what at the business logic level (Users
with role user-admin-foo, can add users to the user group foo). The next
level would be to specify who could invoke operations. e.g. users with
add-user permission can call the addUsersToGroup operation. So, if a
someone needs to add a user to group foo, he should have the permissions to
call the addUsersToGroup operation, as well as permissions to add the user
to the foo group (if applicable). So I prefer model 1.

Azeez

On Tue, Apr 19, 2016 at 11:24 AM, Ramith Jayasinghe  wrote:

> Solution 2 seems too rigid. Why? my argument is there could be scenarios
> more than one functionality ( / method) in a product could require same
> functionality.
> if we use class names, things become complicated and cluttered isn't it?
> thoughts?
>
> On Tue, Apr 19, 2016 at 10:02 AM, Sameera Jayasoma 
> wrote:
>
>> The purpose of this meeting was to brainstorm the new permission model
>> for Carbon 5. This mail contain the summary of the meeting. We haven’t
>> finalized anything yet.
>>
>> During the meeting we discussed on service permissions and resource
>> permissions. Service permissions are applied to micro services. These
>> services could be admin services or product specific services. Resource
>> permissions applies to all the resources in our platform. E.g Registry
>> resource, Topic, Queues etc.
>>
>> Let me try to explain the difference using an example. Consider the
>> operation “addUserToGrop” in “UserMgtService”. Here we can define
>> permission at different levels. A user Bob can invoke this method, but Bob
>> cannot add users to group Foo. Granting privileges to invoke this method
>> can be done via service permissions. Restricting Bob from adding user to
>> group Foo can be done via resource permissions.
>>
>> A permission has a name and optional list of actions. There are
>> permissions with just the name and they are usually called named
>> permission. Either we give users named permissions or we don’t. Above
>> mentioned service permissions are named permissions. E.g. Either we allow
>> user to invoke the addUserToGroup method or we don’t. There are no actions
>> associated with this permission. But for resource permissions , there are
>> associated actions. E.g. Registry resources can be added, deleted, updated
>> etc.
>>
>>
>> *Declaring Permissions.*We discussed two ways to declare required
>> permissions in services.
>>
>> *Solution 01*
>>
>> @RequirePermission(“manage/users”)
>> public class UserMgtService {
>>   @RequirePermission(“add-user”)
>>   public  void addUserToGropu(User user, String groupName) {
>>   }
>> }
>>
>> This is exactly same as Carbon 4 model. Permissions required invoke a
>> service is declared in the services.xml. With microservices based services
>> we can declare required permission with annotations.
>>
>> *Solution 02*
>>
>> @Secure
>> public class UserMgtService {
>>public  void addUserToGropu(User user, String groupName) {
>>}
>> }
>>
>> Here we calculate the permission string using the classname and the
>> method name. E.g.
>> org.wso2.carbon.identity.mgt.UserMgtService.addUser. These service
>> permission can be checked with an microservice interceptor.
>>
>> There are pros and cons of both of these methods. We need to discuss and
>> come to a conclusion soon.
>>
>> Also we need to figure out how to declare resource permissions.
>>
>> Thanks,
>> Sameera.
>>
>> --
>> Sameera Jayasoma,
>> Software Architect,
>>
>> WSO2, Inc. (http://wso2.com)
>> email: same...@wso2.com
>> blog: http://blog.sameera.org
>> twitter: https://twitter.com/sameerajayasoma
>> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections
>> Mobile: 0094776364456
>>
>> Lean . Enterprise . Middleware
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Ramith Jayasinghe
> Technical Lead
> WSO2 Inc., http://wso2.com
> lean.enterprise.middleware
>
>

Re: [Architecture] Ports to use for Admin Services in C5

[Afkham Azeez]

Will you run admin stuff & user stuff on the same instances? At least
shouldn't our recommendation be that admin & user stuff have to be
separate, as a best practice?

On Wed, May 4, 2016 at 9:12 PM, Hasitha Aravinda  wrote:

> Hi Manu,
>
> In my point of view, we have to decide it based on what API does and who
> are the actual users involve.
>
> In BPS, we have two sets of users: workflow participants and admin
> user/devOps of the BPS. Based on these users we can categorized BPS APIs
> into two sets.
>
>- Admin APIs : There are few APIs like artifact deployer API, accessed
>only by administrators of the server or devOps.
>
>
>- User APIs : BPMN Rest API and HumanTask API are user APIs, because
>these APIs only accessed by participants of processes and user tasks. But
>we can argue some of the operations are admin operations, but those are
>business admin operations. These resources/operations need to
>be authorized using an ACL, based on current user and his role in workflow
>or user-task.
>
> For example in HumanTask [1], we have several roles i.e. Business
> Administrator, Potential Owners, Excluded Owners, Stakeholders etc. Based
> on current user and his role in defined task, user are authorized to
> perform an operation.
>
> ​IMO having clear separations between User API and Admin API may important
> when securing these APIs separately.
>
> [1] -
> http://docs.oasis-open.org/bpel4people/ws-humantask-1.1-spec-cs-01.html#_Toc261430341
>
> Thanks,
> Hasitha.
>
> On Wed, May 4, 2016 at 7:55 PM, Manuranga Perera  wrote:
>
>> How do we define an admin vs non-admin API?
>> Is getting list of users different from getting the list of processes?
>>
>> A customer written UI may have to call both. We can argue that some
>> things are 100% admin eg: shutdown server. But to me this seems like an
>> arbitrary decision.
>>
>>
>> On Wed, May 4, 2016 at 12:14 AM, Hasitha Aravinda 
>> wrote:
>>
>>> Another thing, we need to consider exposing different ports for user
>>> APIs and Admin APIs to have a clear separation. In C4 all user and admin
>>> APIs exposed in 9443 and 9763. AFAIK this is not supported in current MSF4J
>>> OSGi version.
>>>
>>> Thanks,
>>> Hasitha.
>>>
>>> On Wed, May 4, 2016 at 9:26 AM, Nandika Jayawardana 
>>> wrote:
>>>
>>>> Hi All,
>>>>
>>>> In all the carbon platform versions up to now, we used 9443, and 9763
>>>> ports for admin services for all server products. Are we going to use the
>>>> same ports for C5.
>>>>
>>>> Regards
>>>> Nandika
>>>>
>>>> --
>>>> Nandika Jayawardana
>>>> WSO2 Inc ; http://wso2.com
>>>> lean.enterprise.middleware
>>>>
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> --
>>> Hasitha Aravinda,
>>> Senior Software Engineer,
>>> WSO2 Inc.
>>> Email: hasi...@wso2.com
>>> Mobile : +94 718 210 200
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> With regards,
>> *Manu*ranga Perera.
>>
>> phone : 071 7 70 20 50
>> mail : m...@wso2.com
>>
>
>
>
> --
> --
> Hasitha Aravinda,
> Senior Software Engineer,
> WSO2 Inc.
> Email: hasi...@wso2.com
> Mobile : +94 718 210 200
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919blog: **http://blog.afkham.org*
<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*
<http://twitter.com/afkham_azeez>
*linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Handling product versions in microservices

[Afkham Azeez]

In what cases would you require to maintain multiple versions of a
microservice in a product? Or is this related to different versions of the
same product? If it is the second case, it is the responsibility of the
gateway to route to the correct instances and there is no need to maintain
version information on the product runtime side.

On Thu, May 5, 2016 at 2:12 PM, Sameera Jayasoma  wrote:

>
>
> On Thu, May 5, 2016 at 12:42 PM, Hasitha Aravinda 
> wrote:
>
>> ​Some more questions
>>
>> On Thu, May 5, 2016 at 12:30 PM, Sameera Jayasoma 
>> wrote:
>>
>>> I believe its wrong to use the product version to version your micro
>>> services.
>>>
>>> You need to have different version for your microservices. e.g. starting
>>> from 1.0.0. If you don't change any of your microservices you shouldn't be
>>> changing these versions.
>>>
>>
>> ​According to Rest API guideline, it should be product version. ​isn't it
>> ?
>>
>
> We cannot change API versions for each and every product release.  You
> should change the API version only if you have introduced a change.  We are
> following the same approach to version export packages from bundles.
>
>
>>
>> Let's say we are using version from 1.0.0.
>> ​If we are going to do a modification​
>>
>> ​to a microservice ( ​let's say foo 1.0) and new version is foo 1.1 Do we
>> need to maintain both versions to provide backward compatibility ? If so we
>> have to maintain two microservices: Foo 1.0 and Foo 1.1, because version is
>> a part of the path in microservice.
>>
>
> I am not sure whether need to maintain the previous versions of micro
> services. Thats something we need to discuss. Also it adds complexity.
>
> If you have introduced any additions to your micro services, then you can
> bump up the minor version number. If you've introduced incompatible
> changes, then you have bump up the major version number.
>
>
>
>>
>> eg:
>> @Path("
>> /bps/bpmn/v
>> ​1​
>> .0/
>> ​foo
>> ")
>> ​ ,
>> @Path("
>> /bps/bpmn/v
>> ​1​
>> .
>> ​1​
>> /
>> ​foo
>> ")
>> ​
>> Thanks,
>> Hasitha.
>>
>>
>>> On Thu, May 5, 2016 at 11:02 AM, Himasha Guruge 
>>> wrote:
>>>
>>>> Hi All,
>>>>
>>>> We have refactored our REST APIs by implementing Microservice
>>>> interface. According to the new REST guideline , we need to maintain the
>>>> URL format like below. For example,
>>>>
>>>> http://localhost:/bps/bpmn/v4.0/repository/deployments
>>>>
>>>> How are we going to maintain the product version updates with
>>>> microservices? If we are to maintain the product version with a  parameter
>>>> been set from a config file, how can we achieve this?
>>>>
>>>>
>>>> Thanks,
>>>> Himasha Guruge
>>>> *Software Engineer*
>>>> WS*O2* *Inc.*
>>>> Mobile: +94 777459299
>>>> himas...@wso2.com
>>>>
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> Sameera Jayasoma,
>>> Software Architect,
>>>
>>> WSO2, Inc. (http://wso2.com)
>>> email: same...@wso2.com
>>> blog: http://blog.sameera.org
>>> twitter: https://twitter.com/sameerajayasoma
>>> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections
>>> Mobile: 0094776364456
>>>
>>> Lean . Enterprise . Middleware
>>>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> --
>> Hasitha Aravinda,
>> Senior Software Engineer,
>> WSO2 Inc.
>> Email: hasi...@wso2.com
>> Mobile : +94 718 210 200
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Sameera Jayasoma,
> Software Architect,
>
> WSO2, Inc. (http://wso2.com)
> email: same...@wso2.com
> blog: http://blog.sameera.org
> twitter: https://twitter.com/sameerajayasoma
> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections
> Mobile: 0094776364456
>
> Lean . Enterprise . Middleware
>
>


-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919blog: **http://blog.afkham.org*
<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*
<http://twitter.com/afkham_azeez>
*linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Ports to use for Admin Services in C5

[Afkham Azeez]

There is a way to do this. At the point of deploying the service, you have
to specify on which transports that service is exposed. This is similar to
the concept of exposing services on selected transports in Axis2.

On Fri, May 6, 2016 at 2:26 PM, Sagara Gunathunga  wrote:

>
>
> On Thu, May 5, 2016 at 2:32 PM, Kishanthan Thangarajah <
> kishant...@wso2.com> wrote:
>
>> Another thing is, should we also work on exposing admin services on one
>> listener (probably over https) and other user api's on different listener?
>> May be we need to bring in some changes to MSF4J core to support this via
>> OSGi level service properties and listener id's.
>>
>
> Usually it uses separate port for admin services so that that port can be
> protected with high level of security, +1 explore this option.
>
> Thanks !
>
>>
>>
>> On Thu, May 5, 2016 at 7:39 AM, Afkham Azeez  wrote:
>>
>>> Will you run admin stuff & user stuff on the same instances? At least
>>> shouldn't our recommendation be that admin & user stuff have to be
>>> separate, as a best practice?
>>>
>>> On Wed, May 4, 2016 at 9:12 PM, Hasitha Aravinda 
>>> wrote:
>>>
>>>> Hi Manu,
>>>>
>>>> In my point of view, we have to decide it based on what API does and
>>>> who are the actual users involve.
>>>>
>>>> In BPS, we have two sets of users: workflow participants and admin
>>>> user/devOps of the BPS. Based on these users we can categorized BPS APIs
>>>> into two sets.
>>>>
>>>>- Admin APIs : There are few APIs like artifact deployer API,
>>>>accessed only by administrators of the server or devOps.
>>>>
>>>>
>>>>- User APIs : BPMN Rest API and HumanTask API are user APIs,
>>>>because these APIs only accessed by participants of processes and user
>>>>tasks. But we can argue some of the operations are admin operations, but
>>>>those are business admin operations. These resources/operations need to
>>>>be authorized using an ACL, based on current user and his role in 
>>>> workflow
>>>>or user-task.
>>>>
>>>> For example in HumanTask [1], we have several roles i.e. Business
>>>> Administrator, Potential Owners, Excluded Owners, Stakeholders etc. Based
>>>> on current user and his role in defined task, user are authorized to
>>>> perform an operation.
>>>>
>>>> ​IMO having clear separations between User API and Admin API may
>>>> important when securing these APIs separately.
>>>>
>>>> [1] -
>>>> http://docs.oasis-open.org/bpel4people/ws-humantask-1.1-spec-cs-01.html#_Toc261430341
>>>>
>>>> Thanks,
>>>> Hasitha.
>>>>
>>>> On Wed, May 4, 2016 at 7:55 PM, Manuranga Perera  wrote:
>>>>
>>>>> How do we define an admin vs non-admin API?
>>>>> Is getting list of users different from getting the list of processes?
>>>>>
>>>>> A customer written UI may have to call both. We can argue that some
>>>>> things are 100% admin eg: shutdown server. But to me this seems like an
>>>>> arbitrary decision.
>>>>>
>>>>>
>>>>> On Wed, May 4, 2016 at 12:14 AM, Hasitha Aravinda 
>>>>> wrote:
>>>>>
>>>>>> Another thing, we need to consider exposing different ports for user
>>>>>> APIs and Admin APIs to have a clear separation. In C4 all user and admin
>>>>>> APIs exposed in 9443 and 9763. AFAIK this is not supported in current 
>>>>>> MSF4J
>>>>>> OSGi version.
>>>>>>
>>>>>> Thanks,
>>>>>> Hasitha.
>>>>>>
>>>>>> On Wed, May 4, 2016 at 9:26 AM, Nandika Jayawardana >>>>> > wrote:
>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> In all the carbon platform versions up to now, we used 9443, and
>>>>>>> 9763 ports for admin services for all server products. Are we going to 
>>>>>>> use
>>>>>>> the same ports for C5.
>>>>>>>
>>>>>>> Regards
>>>>>>> Nandika
>>>>>>>
>>>>>>> --
>>>>>>> Nandika Jayawardana
>>>>>>

Re: [Architecture] [Dev] OOM Issues and HazelCast behaviour

[Afkham Azeez]

System.exit(121) triggers a restart in Carbon. This was there in Carbon 4,
but we can add it to Carbon 5 as well.

On Tue, May 10, 2016 at 2:18 PM, Srinath Perera  wrote:

> +1, when server hits an issue it cannot recover and continue to work
> meaningfully, it is best to shut down or restart. That approximate crash
> failure behaviour ( which is a good thing).
>
> On Tue, May 10, 2016 at 11:40 AM, Ramith Jayasinghe 
> wrote:
>
>> HI Azeez/Sameera,
>>
>>  Having encountered some OOM issues (relating to HZ) I looked at what
>> Hazelcast does in face of GC errors [1]. It will drop all connections,
>> threads, and shuts it self down.
>>
>> Now, Think about one of our server's ( say MB) face a OOM and embedded HZ
>> instance shuts it self down. I propose when this happens entire server
>> should stop its processing intelligently ( if not shutting down).
>> Rational is one of the sub-system in the server shutdown while other
>> parts of the server don't care, which is wrong. As for MB, it tries to stop
>> processing in a meaningful manner and I argue this should be something any
>> server should do if they use HZ clustering.
>>
>> thoughts?
>>
>>
>> [1]
>> https://github.com/hazelcast/hazelcast/blob/master/hazelcast/src/main/java/com/hazelcast/instance/DefaultOutOfMemoryHandler.java
>>
>> --
>> Ramith Jayasinghe
>> Technical Lead
>> WSO2 Inc., http://wso2.com
>> lean.enterprise.middleware
>>
>> E: ram...@wso2.com
>> P: +94 772534930
>>
>> ___
>> Dev mailing list
>> d...@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> 
> Srinath Perera, Ph.D.
>http://people.apache.org/~hemapani/
>http://srinathsview.blogspot.com/
>



-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919blog: **http://blog.afkham.org*
<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*
<http://twitter.com/afkham_azeez>
*linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] MSF4J 1.1.0 and API-M 1.10.0 using Swagger

[Afkham Azeez]

On Mon, May 23, 2016 at 9:42 PM, Senaka Fernando  wrote:

> Hi all,
>
> I'm working on pulling a demo together based on $subject. So, good news is
> that it works nearly perfectly. But, then there were a few things that I
> noted.
>
>1. API-M is unable to process the Swagger URL presented by MSF4J (due
>to inverted commas, AFAIU).
>
> What inverted commas? Swagger URL is like this:

http://localhost:8080/swagger?path=/stockquote


>
>1. It parses the Swagger file well, but there were two issues:
>   1. It uses the Title and the default one presented by MSF4J has
>   spaces and won't work - (so had to fix the sample - but that's fine).
>
>
Can you post an example?


>
>1.
>   2. It doesn't extract the context from the Swagger file
>   appropriately, but appends that into the resources on the API 
> definition.
>   So, if you stick to the defaults, the URL looks a little ugly, "
>   http://localhost:8280/*stockquote*/1.0/*stockquote*/IBM";
>
> Are these things for which we have fixes/workarounds?
>
> Thanks,
> Senaka.
> --
>
>
> *[image: http://wso2.com] <http://wso2.com>Senaka Fernando*
> Solutions Architect; WSO2 Inc.; http://wso2.com
>
>
>
> *Member; Apache Software Foundation; http://apache.org
> <http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P: +44
> 203 318 6025 <%2B44%20203%20318%206025>;*
>
>
> *M: +44 782 741 1966 <%2B44%20782%20741%201966>Linked-In:
> http://linkedin.com/in/senakafernando
> <http://linkedin.com/in/senakafernando>*Lean . Enterprise . Middleware
>



-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919blog: **http://blog.afkham.org*
<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*
<http://twitter.com/afkham_azeez>
*linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] MSF4J 1.1.0 and API-M 1.10.0 using Swagger

[Afkham Azeez]

On Tue, May 24, 2016 at 12:10 AM, Afkham Azeez  wrote:

>
>
> On Mon, May 23, 2016 at 9:42 PM, Senaka Fernando  wrote:
>
>> Hi all,
>>
>> I'm working on pulling a demo together based on $subject. So, good news
>> is that it works nearly perfectly. But, then there were a few things that I
>> noted.
>>
>>1. API-M is unable to process the Swagger URL presented by MSF4J (due
>>to inverted commas, AFAIU).
>>
>> What inverted commas? Swagger URL is like this:
>
> http://localhost:8080/swagger?path=/stockquote
>
>
>>
>>1. It parses the Swagger file well, but there were two issues:
>>   1. It uses the Title and the default one presented by MSF4J has
>>   spaces and won't work - (so had to fix the sample - but that's fine).
>>
>>
> Can you post an example?
>

Did you mean this: "title" : "Stockquote Swagger Definition"

>
>
>>
>>1.
>>   2. It doesn't extract the context from the Swagger file
>>   appropriately, but appends that into the resources on the API 
>> definition.
>>   So, if you stick to the defaults, the URL looks a little ugly, "
>>   http://localhost:8280/*stockquote*/1.0/*stockquote*/IBM";
>>
>> Are these things for which we have fixes/workarounds?
>>
>> Thanks,
>> Senaka.
>> --
>>
>>
>> *[image: http://wso2.com] <http://wso2.com>Senaka Fernando*
>> Solutions Architect; WSO2 Inc.; http://wso2.com
>>
>>
>>
>> *Member; Apache Software Foundation; http://apache.org
>> <http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P: +44
>> 203 318 6025 <%2B44%20203%20318%206025>;*
>>
>>
>> *M: +44 782 741 1966 <%2B44%20782%20741%201966>Linked-In:
>> http://linkedin.com/in/senakafernando
>> <http://linkedin.com/in/senakafernando>*Lean . Enterprise . Middleware
>>
>
>
>
> --
> *Afkham Azeez*
> Director of Architecture; WSO2, Inc.; http://wso2.com
> Member; Apache Software Foundation; http://www.apache.org/
> * <http://www.apache.org/>*
> *email: **az...@wso2.com* 
> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: *
> *http://blog.afkham.org* <http://blog.afkham.org>
> *twitter: **http://twitter.com/afkham_azeez*
> <http://twitter.com/afkham_azeez>
> *linked-in: **http://lk.linkedin.com/in/afkhamazeez
> <http://lk.linkedin.com/in/afkhamazeez>*
>
> *Lean . Enterprise . Middleware*
>



-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919blog: **http://blog.afkham.org*
<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*
<http://twitter.com/afkham_azeez>
*linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] MSF4J 1.1.0 and API-M 1.10.0 using Swagger

[Afkham Azeez]

README has been fixed

On Tue, May 24, 2016 at 1:28 AM, Senaka Fernando  wrote:

>
>
> On Mon, May 23, 2016 at 8:57 PM, Senaka Fernando  wrote:
>
>> Hi Azeez,
>>
>> Thanks for getting back. Sorry I was in a hurry putting a demo together
>> for Thursday - reading your replies, I see that I haven't explained a few
>> things.
>>
>> On Mon, May 23, 2016 at 7:42 PM, Afkham Azeez  wrote:
>>
>>>
>>>
>>> On Tue, May 24, 2016 at 12:10 AM, Afkham Azeez  wrote:
>>>
>>>>
>>>>
>>>> On Mon, May 23, 2016 at 9:42 PM, Senaka Fernando 
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I'm working on pulling a demo together based on $subject. So, good
>>>>> news is that it works nearly perfectly. But, then there were a few things
>>>>> that I noted.
>>>>>
>>>>>1. API-M is unable to process the Swagger URL presented by MSF4J
>>>>>(due to inverted commas, AFAIU).
>>>>>
>>>>> What inverted commas? Swagger URL is like this:
>>>>
>>>> http://localhost:8080/swagger?path=/stockquote
>>>>
>>>
>> That works. Sorry - I should have tried that. But, we have to fix the
>> README(s), [1].
>>
>
> Sorry, [1]
> https://github.com/wso2/msf4j/blob/master/samples/stockquote/fatjar/README.md
>
>
>> The URL points to the right place, but the text is wrong.
>>
>> I copied that and didn't think much since the file import worked well.
>> Also, the microservice responds with and without inverted commas (i.e. curl
>> http://localhost:8080/swagger?path=/stockquote > 1.out; curl
>> http://localhost:8080/swagger?path="/stockquote"; > 2.out; diff 1.out
>> 2.out).
>>
>>>
>>>>
>>>>>
>>>>>1. It parses the Swagger file well, but there were two issues:
>>>>>   1. It uses the Title and the default one presented by MSF4J has
>>>>>   spaces and won't work - (so had to fix the sample - but that's 
>>>>> fine).
>>>>>
>>>>>
>>>> Can you post an example?
>>>>
>>>
>>> Did you mean this: "title" : "Stockquote Swagger Definition"
>>>
>>
>> Yes, that is what I meant. I fixed this in the
>> src/main/java/org/wso2/msf4j/example/StockQuoteService.java class to
>> "StockQuote". May be it is not an issue of MSF4J, but API-M. But, if you
>> try to create a new API with
>> http://localhost:8080/swagger?path=/stockquote as the Swagger URL, API-M
>> fails.
>>
>>>
>>>>
>>>>>
>>>>>1.
>>>>>   2. It doesn't extract the context from the Swagger file
>>>>>   appropriately, but appends that into the resources on the API 
>>>>> definition.
>>>>>   So, if you stick to the defaults, the URL looks a little ugly, "
>>>>>   http://localhost:8280/*stockquote*/1.0/*stockquote*/IBM";
>>>>>
>>>>> For the point above of course, I didn't find any workaround.
>>
>> Thanks,
>> Senaka.
>>
>>>
>>>>>1.
>>>>>
>>>>> Are these things for which we have fixes/workarounds?
>>>>>
>>>>> Thanks,
>>>>> Senaka.
>>>>> --
>>>>>
>>>>>
>>>>> *[image: http://wso2.com] <http://wso2.com>Senaka Fernando*
>>>>> Solutions Architect; WSO2 Inc.; http://wso2.com
>>>>>
>>>>>
>>>>>
>>>>> *Member; Apache Software Foundation; http://apache.org
>>>>> <http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P:
>>>>> +44 203 318 6025 <%2B44%20203%20318%206025>;*
>>>>>
>>>>>
>>>>> *M: +44 782 741 1966 <%2B44%20782%20741%201966>Linked-In:
>>>>> http://linkedin.com/in/senakafernando
>>>>> <http://linkedin.com/in/senakafernando>*Lean . Enterprise . Middleware
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> *Afkham Azeez*
>>>> Director of Architecture; WSO2, Inc.; http://wso2.com
>>>> Member; Apache Software Foundation; http://www.apache.org/
>>>> * <http://www.apache.org/>*
>>>> *email: **az...@w

Re: [Architecture] [C5] Java Util Logging vs Pax Logging for C5

[Afkham Azeez]

Your stress test is a purely theoretical one. There will be no instance
where a server writes 100k logs or 1m logs simultaneously. If that happens,
we will have other problems like quickly running out of disk space, for
example. Hence I think for all practical purposes, JUL is good.

On Tue, May 24, 2016 at 3:36 PM, KasunG Gajasinghe  wrote:

> Hi,
>
> We have done an initial POC on the affect of logging framework for the C5
> server startup between SLF4J (via pax logging) and JUL. Below are the
> initial findings.
>
> *TL;DR* The c5 kernel starts in *0.7 seconds* with JUL, a 350ms decrease
> compared to pax-logging. But the time taken to log under a load test is
> quiet high for JUL.
>
> Product tested - wso2carbon-kernel-5.1.0-SNAPSHOT
> JDK - 1.8.0_60
> OS  - OS X El Capitan
>
> Pax-Logging (SLF4J) Java Util Logging
> startup 1.059s 0.705s
> 100k logs 4.5s 7.9s
> 1m logs 23.482s 57.723s
>
>
> Current C5 kernel uses SLF4J API provided Pax-Logging. Pax-Logging uses
> Log4J 2 as the back-end. With that, the server startup is around 1.059s.
> The server startup decreased by around 350 ms after removing pax-logging
> and replacing the slf4j logs with java util logging.
>
> It seems that log4j2 loads ~750 classes to find classes with @Plugin
> annotation which causes this delay in the startup. This seems to be
> essential for its function.
>
> [image: Inline image 2]
>
> As the number of logs increases, the time taken to log all the log entries
> increased considerably with java util logging.
>
> [image: Inline image 3]
>
> With these numbers, not sure whether we want to go with JUL.
>
>
>
> --
>
> *Kasun Gajasinghe*Senior Software Engineer, WSO2 Inc.
> email: kasung AT spamfree wso2.com
> linked-in: http://lk.linkedin.com/in/gajasinghe
> blog: http://kasunbg.org
>
>
>



-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919blog: **http://blog.afkham.org*
<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*
<http://twitter.com/afkham_azeez>
*linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Do we need a House Keeping Task for C5 Based Products

[Afkham Azeez]

I think we should rely on the components that create garbage to clear out
their own garbage without having a central task in the kernel.

On Tue, Jun 7, 2016 at 3:29 PM, Thusitha Thilina Dayaratne <
thusit...@wso2.com> wrote:

> Hi All,
>
> I'm trying to implement file upload support for msf4j with FormParam. In
> the none streaming mode, we need to create temp files in some location and
> clean them after a particular time period.
>
> For that purpose at the moment I'm using apache commons-io provided
> FileCleaningTracker[1, 2]. There we can give the set of file objects that
> we need to track. This will be running in a separate thread. When those
> objects are eligible for GC, it will delete the those files. In this way we
> can be sure that the temp objects will not get clear before the actual
> service consumes them.
>
> IMHO it would be much easier if we can provide a similar support from the
> kernel level, since products will require similar functionality in the
> future.
>
> AFAIU rather than tracking the file object references, if we run this as a
> periodic task (like in c4) we have to assume that the temp files are been
> consumed after a pre-configured time. Is it safe to assume so?
>
> WDYT?
>
> [1] -
> https://commons.apache.org/proper/commons-io/javadocs/api-2.2/org/apache/commons/io/FileCleaningTracker.html
> [2] -
> https://github.com/apache/commons-io/blob/trunk/src/main/java/org/apache/commons/io/FileCleaningTracker.java
>
> Thanks
> --
> Thusitha Dayaratne
> Software Engineer
> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>
> Mobile  +94712756809
> Blog  alokayasoya.blogspot.com
> Abouthttp://about.me/thusithathilina
>
>


-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919blog: **http://blog.afkham.org*
<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*
<http://twitter.com/afkham_azeez>
*linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Securing communication between Hazelcast and WSO2 servers

[Afkham Azeez]

Yes securing the cluster channel is available only in enterprise Hazelcast
& for 4.4 based releases, it requires a kernel patch we have released as
well.
On Jun 14, 2016 12:22 PM, "Srinath Perera"  wrote:

> I think it is only for enterprise version.
>
> Right deployment architecture is to secure it through a firewall.
> Basically, only designated nodes should be able to connect to the hazelcast
> cluster.
>
> --srinath
>
>
>
> On Mon, Jun 13, 2016 at 10:36 PM, Hasitha Hiranya 
> wrote:
>
>> Hi,
>>
>> When a cluster is setup out of WSO2 servers Hazelcast is configured to
>>
>> 1. Make cluster calls across nodes (push notifications)
>> 2. Use as a distributed cache among the nodes
>>
>> Is there any possibility for a third party Hazelcast client to come and
>> consume this data or push un-relevant notifications to the nodes? Also, are
>> we storing sensitive data in HZ cache?
>>
>> Hazelcast communication is happening inside MZ. But yet some companies
>> would like to make it secured.
>>
>> SSL can be configured at HZ client level as per [1], but not sure if it
>> only for enterprise.
>>
>> [1]. http://docs.hazelcast.org/docs/3.5/manual/html/ssl.html
>>
>> Thanks
>>
>> --
>> *Hasitha Abeykoon*
>> Senior Software Engineer; WSO2, Inc.; http://wso2.com
>> *cell:* *+94 719363063*
>> *blog: **abeykoon.blogspot.com* 
>>
>>
>
>
> --
> 
> Blog: http://srinathsview.blogspot.com twitter:@srinath_perera
> Site: http://home.apache.org/~hemapani/
> Photos: http://www.flickr.com/photos/hemapani/
> Phone: 0772360902
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] MSF4J Helloworld sample size > 20 MB ?

[Afkham Azeez]

Yes;

ls -al target/helloworld-1.1.0-SNAPSHOT.jar

-rw-r--r--  1 azeez  staff  *1143* Jun 16 17:23
target/helloworld-1.1.0-SNAPSHOT.jar



On Fri, Jun 17, 2016 at 1:52 PM, Thusitha Thilina Dayaratne <
thusit...@wso2.com> wrote:

> Hi Sagara,
>
> In the latest pack the helloworld sample is 12.2 MB. AFAIR Azeeze has
> removed most of the unwanted OSGi stuffs that get bundled.
> Will check on this further.
>
> Thanks
> Thusitha
>
> On Fri, Jun 17, 2016 at 1:43 PM, Sagara Gunathunga 
> wrote:
>
>>
>> In MSF4J 1.1.0-SNAPSHOT version helloworld sample size ( same go for
>> other samples as well)  became 20.1 MB, I don't think this is acceptable
>> size for a such simple sample. By looking at shade plugin I found number of
>> unwanted OSGi Jar files get bundled with the sample's uber Jar file, we
>> have to exclude these unwanted dependencies from parent POM files or need
>> to refractor Carbon-transport not to import those OSGi dependencies
>> automatically WDYT ?
>>
>> [INFO] Including org.wso2.carbon:org.wso2.carbon.kernel.feature:zip:5.1.0
>> in the shaded jar.  ( I don't think we need Zip files here)
>>
>> [INFO] Including org.osgi:org.osgi.core:jar:6.0.0 in the shaded jar.
>> [INFO] Including org.wso2.carbon:org.wso2.carbon.tools.core:jar:5.1.0 in
>> the shaded jar.
>> [INFO] Including
>> org.wso2.carbon:org.wso2.carbon.runtime.feature:zip:5.1.0 in the shaded jar.
>> [INFO] Including
>> org.wso2.eclipse.equinox:org.eclipse.equinox.launcher.gtk.linux.x86:jar:1.1.200.v20150204-1316
>> in the shaded jar.
>> [INFO] Including
>> org.wso2.eclipse.equinox:org.eclipse.equinox.common:jar:3.6.200.v20130402-1505
>> in the shaded jar.
>> [INFO] Including
>> org.wso2.eclipse.equinox:org.eclipse.equinox.simpleconfigurator:jar:1.1.0.v20131217-1203
>> in the shaded jar.
>> [INFO] Including
>> org.wso2.eclipse.equinox:org.eclipse.equinox.util:jar:1.0.500.v20130404-1337
>> in the shaded jar.
>> [INFO] Including
>> org.wso2.eclipse.equinox:org.eclipse.equinox.ds:jar:1.4.200.v20131126-2331
>> in the shaded jar.
>> [INFO] Including
>> org.wso2.eclipse.equinox:org.eclipse.equinox.launcher:jar:1.3.0.v20140415-2008
>> in the shaded jar.
>> [INFO] Including
>> org.wso2.eclipse.equinox:org.eclipse.equinox.concurrent:jar:1.1.0.v20130327-1442
>> in the shaded jar.
>> [INFO] Including
>> org.wso2.eclipse.equinox:org.eclipse.equinox.frameworkadmin:jar:2.0.100.v20131209-2144
>> in the shaded jar.
>> [INFO] Including
>> org.wso2.eclipse.equinox:org.eclipse.equinox.frameworkadmin.equinox:jar:1.0.500.v20131211-1531
>> in the shaded jar.
>> [INFO] Including
>> org.wso2.eclipse.equinox:org.eclipse.equinox.console:jar:1.1.0.v20140131-1639
>> in the shaded jar.
>> [INFO] Including
>> org.apache.felix:org.apache.felix.gogo.command:jar:0.10.0.v201209301215 in
>> the shaded jar.
>> [INFO] Including
>> org.apache.felix:org.apache.felix.gogo.shell:jar:0.10.0.v201212101605 in
>> the shaded jar.
>> [INFO] Including
>> org.apache.felix:org.apache.felix.gogo.runtime:jar:0.10.0.v201209301036 in
>> the shaded jar.
>> [INFO] Including org.ops4j.pax.logging:pax-logging-api:jar:1.8.5 in the
>> shaded jar.
>> [INFO] Including org.ops4j.pax.logging:pax-logging-log4j2:jar:1.8.5 in
>> the shaded jar.
>> [INFO] Including 
>> org.wso2.eclipse.equinox:org.eclipse.equinox.cm:jar:1.1.0.v20131021-1936
>> in the shaded jar.
>> [INFO] Including
>> org.wso2.eclipse.equinox:org.eclipse.equinox.preferences:jar:3.5.200.v20140224-1527
>> in the shaded jar.
>> [INFO] Including
>> org.wso2.eclipse.equinox:org.eclipse.equinox.simpleconfigurator.manipulator:jar:2.0.0.v20131217-1203
>> in the shaded jar.
>> [INFO] Including
>> org.wso2.eclipse.osgi:org.eclipse.osgi.compatibility.state:jar:1.0.1.v20140709-1414
>> in the shaded jar.
>>
>>
>>
>>
>> Thanks !
>> --
>> Sagara Gunathunga
>>
>> Architect; WSO2, Inc.;  http://wso2.com
>> V.P Apache Web Services;http://ws.apache.org/
>> Linkedin; http://www.linkedin.com/in/ssagara
>> Blog ;  http://ssagara.blogspot.com
>>
>>
>
>
> --
> Thusitha Dayaratne
> Software Engineer
> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>
> Mobile  +94712756809
> Blog  alokayasoya.blogspot.com
> Abouthttp://about.me/thusithathilina
>
>


-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919blog: **http://blog.afkham.org*
<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*
<http://twitter.com/afkham_azeez>
*linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Initial Implementation of content-aware support in Carbon-Gateway

[Afkham Azeez]

 read
>>>>>via XPath or JSONPath according to  the  content type.
>>>>>-
>>>>>
>>>>> When message hits the content aware mediator it checks weather
>>>>>message is already read if so then it takes MessageDataSource which is 
>>>>> data
>>>>>holder for already read message inputstream according contentType.Else 
>>>>> it
>>>>>gets the matching reader from reader registry and read the input 
>>>>> stream and
>>>>>load the inputstream into MessageDataSource.
>>>>>-
>>>>>
>>>>>XPath and JSONPath are evaluated using MessageDataSource
>>>>>-
>>>>>
>>>>>Serialize data from MessageDataSource to CarbonMessage before
>>>>>sending to the transport level after mediation.
>>>>>
>>>>>
>>>>>
>>>>> XML Reading
>>>>>
>>>>>-
>>>>>
>>>>>Axiom is used for represent XML messages as OMElements
>>>>>-
>>>>>
>>>>>Axiom uses StAX API for read and write XML messages which is
>>>>>inherently supports deferred building concept.
>>>>>-
>>>>>
>>>>>AxiomXpath is used for evaluate XPath and it used Jaxen as
>>>>>underlying XPath library.
>>>>>-
>>>>>
>>>>>XPath libraries are pluggable.
>>>>>
>>>>>
>>>>>
>>>>> JSON Reading
>>>>>
>>>>>-
>>>>>
>>>>>Jayway library is used for represent JSONPath.
>>>>>-
>>>>>
>>>>>Underlying JSON library is Jackson.
>>>>>-
>>>>>
>>>>>Jackson has JSONParser and JSONGenerator which are similar to
>>>>>StreamingXMLReader and Writer in StAX API and can read,  write events 
>>>>> in
>>>>>streaming manner.
>>>>>- Jackson supports data binding as well.
>>>>>
>>>>>
>>>>> Thanks
>>>>> --
>>>>> Best Regards
>>>>> Isuru Ranawaka
>>>>> M: +94714629880
>>>>> Blog : http://isurur.blogspot.com/
>>>>> ___
>>>>> Architecture mailing list
>>>>> Architecture@wso2.org
>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>
>>>>
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> Best Regards
>>> Isuru Ranawaka
>>> M: +94714629880
>>> Blog : http://isurur.blogspot.com/
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Nandika Jayawardana
>> WSO2 Inc ; http://wso2.com
>> lean.enterprise.middleware
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Best Regards
> Isuru Ranawaka
> M: +94714629880
> Blog : http://isurur.blogspot.com/
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919blog: **http://blog.afkham.org*
<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*
<http://twitter.com/afkham_azeez>
*linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] MSF4J Helloworld sample size > 20 MB ?

[Afkham Azeez]

I have tried removing these dependencies but it is not possible because
these are transitive dependencies of some of the msf4j-core's dependencies
and are required at runtime.

On Fri, Jun 17, 2016 at 2:47 PM, Sagara Gunathunga  wrote:

> Got update and reduced file size to 12 MB.
>
> BTW can't we reduce dependencies further ?  As an example we have bundled
> 3 JSON libraries (Gson, Json-smart, Jackson ) and 2 logging APIs
> ( commons-logging and SLF4J ) with above sample.
>
> Thanks !
>
> On Fri, Jun 17, 2016 at 1:55 PM, Afkham Azeez  wrote:
>
>> Yes;
>>
>> ls -al target/helloworld-1.1.0-SNAPSHOT.jar
>>
>> -rw-r--r--  1 azeez  staff  *1143* Jun 16 17:23
>> target/helloworld-1.1.0-SNAPSHOT.jar
>>
>>
>>
>> On Fri, Jun 17, 2016 at 1:52 PM, Thusitha Thilina Dayaratne <
>> thusit...@wso2.com> wrote:
>>
>>> Hi Sagara,
>>>
>>> In the latest pack the helloworld sample is 12.2 MB. AFAIR Azeeze has
>>> removed most of the unwanted OSGi stuffs that get bundled.
>>> Will check on this further.
>>>
>>> Thanks
>>> Thusitha
>>>
>>> On Fri, Jun 17, 2016 at 1:43 PM, Sagara Gunathunga 
>>> wrote:
>>>
>>>>
>>>> In MSF4J 1.1.0-SNAPSHOT version helloworld sample size ( same go for
>>>> other samples as well)  became 20.1 MB, I don't think this is acceptable
>>>> size for a such simple sample. By looking at shade plugin I found number of
>>>> unwanted OSGi Jar files get bundled with the sample's uber Jar file, we
>>>> have to exclude these unwanted dependencies from parent POM files or need
>>>> to refractor Carbon-transport not to import those OSGi dependencies
>>>> automatically WDYT ?
>>>>
>>>> [INFO] Including
>>>> org.wso2.carbon:org.wso2.carbon.kernel.feature:zip:5.1.0 in the shaded jar.
>>>>  ( I don't think we need Zip files here)
>>>>
>>>> [INFO] Including org.osgi:org.osgi.core:jar:6.0.0 in the shaded jar.
>>>> [INFO] Including org.wso2.carbon:org.wso2.carbon.tools.core:jar:5.1.0
>>>> in the shaded jar.
>>>> [INFO] Including
>>>> org.wso2.carbon:org.wso2.carbon.runtime.feature:zip:5.1.0 in the shaded 
>>>> jar.
>>>> [INFO] Including
>>>> org.wso2.eclipse.equinox:org.eclipse.equinox.launcher.gtk.linux.x86:jar:1.1.200.v20150204-1316
>>>> in the shaded jar.
>>>> [INFO] Including
>>>> org.wso2.eclipse.equinox:org.eclipse.equinox.common:jar:3.6.200.v20130402-1505
>>>> in the shaded jar.
>>>> [INFO] Including
>>>> org.wso2.eclipse.equinox:org.eclipse.equinox.simpleconfigurator:jar:1.1.0.v20131217-1203
>>>> in the shaded jar.
>>>> [INFO] Including
>>>> org.wso2.eclipse.equinox:org.eclipse.equinox.util:jar:1.0.500.v20130404-1337
>>>> in the shaded jar.
>>>> [INFO] Including
>>>> org.wso2.eclipse.equinox:org.eclipse.equinox.ds:jar:1.4.200.v20131126-2331
>>>> in the shaded jar.
>>>> [INFO] Including
>>>> org.wso2.eclipse.equinox:org.eclipse.equinox.launcher:jar:1.3.0.v20140415-2008
>>>> in the shaded jar.
>>>> [INFO] Including
>>>> org.wso2.eclipse.equinox:org.eclipse.equinox.concurrent:jar:1.1.0.v20130327-1442
>>>> in the shaded jar.
>>>> [INFO] Including
>>>> org.wso2.eclipse.equinox:org.eclipse.equinox.frameworkadmin:jar:2.0.100.v20131209-2144
>>>> in the shaded jar.
>>>> [INFO] Including
>>>> org.wso2.eclipse.equinox:org.eclipse.equinox.frameworkadmin.equinox:jar:1.0.500.v20131211-1531
>>>> in the shaded jar.
>>>> [INFO] Including
>>>> org.wso2.eclipse.equinox:org.eclipse.equinox.console:jar:1.1.0.v20140131-1639
>>>> in the shaded jar.
>>>> [INFO] Including
>>>> org.apache.felix:org.apache.felix.gogo.command:jar:0.10.0.v201209301215 in
>>>> the shaded jar.
>>>> [INFO] Including
>>>> org.apache.felix:org.apache.felix.gogo.shell:jar:0.10.0.v201212101605 in
>>>> the shaded jar.
>>>> [INFO] Including
>>>> org.apache.felix:org.apache.felix.gogo.runtime:jar:0.10.0.v201209301036 in
>>>> the shaded jar.
>>>> [INFO] Including org.ops4j.pax.logging:pax-logging-api:jar:1.8.5 in the
>>>> shaded jar.
>>>> [INFO] Including org.ops4j.pax.logging:pax-logging-log4j2:jar:1.8.5 in
>>>> the shaded jar.
>>>> [INFO] Including 
>>>> org.wso2.ecl

Re: [Architecture] MSF4J Helloworld sample size > 20 MB ?

[Afkham Azeez]

Now the size is down to 9MB. Excluded Nimbus JWT library.

On Wed, Jun 22, 2016 at 2:55 PM, Afkham Azeez  wrote:

> I have tried removing these dependencies but it is not possible because
> these are transitive dependencies of some of the msf4j-core's dependencies
> and are required at runtime.
>
> On Fri, Jun 17, 2016 at 2:47 PM, Sagara Gunathunga 
> wrote:
>
>> Got update and reduced file size to 12 MB.
>>
>> BTW can't we reduce dependencies further ?  As an example we have bundled
>> 3 JSON libraries (Gson, Json-smart, Jackson ) and 2 logging APIs
>> ( commons-logging and SLF4J ) with above sample.
>>
>> Thanks !
>>
>> On Fri, Jun 17, 2016 at 1:55 PM, Afkham Azeez  wrote:
>>
>>> Yes;
>>>
>>> ls -al target/helloworld-1.1.0-SNAPSHOT.jar
>>>
>>> -rw-r--r--  1 azeez  staff  *1143* Jun 16 17:23
>>> target/helloworld-1.1.0-SNAPSHOT.jar
>>>
>>>
>>>
>>> On Fri, Jun 17, 2016 at 1:52 PM, Thusitha Thilina Dayaratne <
>>> thusit...@wso2.com> wrote:
>>>
>>>> Hi Sagara,
>>>>
>>>> In the latest pack the helloworld sample is 12.2 MB. AFAIR Azeeze has
>>>> removed most of the unwanted OSGi stuffs that get bundled.
>>>> Will check on this further.
>>>>
>>>> Thanks
>>>> Thusitha
>>>>
>>>> On Fri, Jun 17, 2016 at 1:43 PM, Sagara Gunathunga 
>>>> wrote:
>>>>
>>>>>
>>>>> In MSF4J 1.1.0-SNAPSHOT version helloworld sample size ( same go for
>>>>> other samples as well)  became 20.1 MB, I don't think this is acceptable
>>>>> size for a such simple sample. By looking at shade plugin I found number 
>>>>> of
>>>>> unwanted OSGi Jar files get bundled with the sample's uber Jar file, we
>>>>> have to exclude these unwanted dependencies from parent POM files or need
>>>>> to refractor Carbon-transport not to import those OSGi dependencies
>>>>> automatically WDYT ?
>>>>>
>>>>> [INFO] Including
>>>>> org.wso2.carbon:org.wso2.carbon.kernel.feature:zip:5.1.0 in the shaded 
>>>>> jar.
>>>>>  ( I don't think we need Zip files here)
>>>>>
>>>>> [INFO] Including org.osgi:org.osgi.core:jar:6.0.0 in the shaded jar.
>>>>> [INFO] Including org.wso2.carbon:org.wso2.carbon.tools.core:jar:5.1.0
>>>>> in the shaded jar.
>>>>> [INFO] Including
>>>>> org.wso2.carbon:org.wso2.carbon.runtime.feature:zip:5.1.0 in the shaded 
>>>>> jar.
>>>>> [INFO] Including
>>>>> org.wso2.eclipse.equinox:org.eclipse.equinox.launcher.gtk.linux.x86:jar:1.1.200.v20150204-1316
>>>>> in the shaded jar.
>>>>> [INFO] Including
>>>>> org.wso2.eclipse.equinox:org.eclipse.equinox.common:jar:3.6.200.v20130402-1505
>>>>> in the shaded jar.
>>>>> [INFO] Including
>>>>> org.wso2.eclipse.equinox:org.eclipse.equinox.simpleconfigurator:jar:1.1.0.v20131217-1203
>>>>> in the shaded jar.
>>>>> [INFO] Including
>>>>> org.wso2.eclipse.equinox:org.eclipse.equinox.util:jar:1.0.500.v20130404-1337
>>>>> in the shaded jar.
>>>>> [INFO] Including
>>>>> org.wso2.eclipse.equinox:org.eclipse.equinox.ds:jar:1.4.200.v20131126-2331
>>>>> in the shaded jar.
>>>>> [INFO] Including
>>>>> org.wso2.eclipse.equinox:org.eclipse.equinox.launcher:jar:1.3.0.v20140415-2008
>>>>> in the shaded jar.
>>>>> [INFO] Including
>>>>> org.wso2.eclipse.equinox:org.eclipse.equinox.concurrent:jar:1.1.0.v20130327-1442
>>>>> in the shaded jar.
>>>>> [INFO] Including
>>>>> org.wso2.eclipse.equinox:org.eclipse.equinox.frameworkadmin:jar:2.0.100.v20131209-2144
>>>>> in the shaded jar.
>>>>> [INFO] Including
>>>>> org.wso2.eclipse.equinox:org.eclipse.equinox.frameworkadmin.equinox:jar:1.0.500.v20131211-1531
>>>>> in the shaded jar.
>>>>> [INFO] Including
>>>>> org.wso2.eclipse.equinox:org.eclipse.equinox.console:jar:1.1.0.v20140131-1639
>>>>> in the shaded jar.
>>>>> [INFO] Including
>>>>> org.apache.felix:org.apache.felix.gogo.command:jar:0.10.0.v201209301215 in
>>>>> the shaded jar.
>>>>> [INFO] Including
>>>>> org.apache.felix:org

Re: [Architecture] How do we get DAS server location?

[Afkham Azeez]

e them is accepting Thrift connections. This is not desirable due
>>> to obvious reasons.
>>>
>>> How shall we proceed?
>>>
>>> Thanks,
>>>
>>> On 30 June 2016 at 08:52, Srinath Perera  wrote:
>>>
>>>> Thanks, sound good. Please do ASAP. We are at beta, so too late even
>>>> now.
>>>>
>>>> --Srinath
>>>>
>>>> On Thu, Jun 30, 2016 at 8:09 AM, Gokul Balakrishnan 
>>>> wrote:
>>>>
>>>>> Hi Srinath,
>>>>>
>>>>> As per our offline chat earlier, the initial plan is to locate
>>>>> the Thrift endpoint  through mDNS service discovery, considering the host
>>>>> and port first.
>>>>>
>>>>> I have used the JmDNS library pointed by Nirmal to do a PoC on this
>>>>> scenario, and I've also already incorporated the logic into the databridge
>>>>> Thrift server to enable service registration through a system property the
>>>>> users could set (-DenableDiscovery). The corresponding client code goes
>>>>> into the publisher OSGi service initialisation. This too is controllable 
>>>>> by
>>>>> the same system property the user could set on the Thrift client (which
>>>>> will be the product talking to DAS/CEP).
>>>>>
>>>>> I'm doing some testing on the entire scenario, and once completed,
>>>>> I'll commit the changes into the relevant repos and send an update to this
>>>>> thread.
>>>>>
>>>>> Thanks,
>>>>>
>>>>>
>>>>> On Thursday, 30 June 2016, Srinath Perera  wrote:
>>>>>
>>>>>> Resending as it hits a filter rule.
>>>>>>
>>>>>> Gokul, please give an update on this?
>>>>>>
>>>>>> --Srinath
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Gokul Balakrishnan
>>>>> Senior Software Engineer,
>>>>> WSO2, Inc. http://wso2.com
>>>>> M +94 77 5935 789 | +44 7563 570502
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> 
>>>> Srinath Perera, Ph.D.
>>>>http://people.apache.org/~hemapani/
>>>>http://srinathsview.blogspot.com/
>>>>
>>>
>>>
>>>
>>> --
>>> Gokul Balakrishnan
>>> Senior Software Engineer,
>>> WSO2, Inc. http://wso2.com
>>> M +94 77 5935 789 | +44 7563 570502
>>>
>>>
>>
>>
>> --
>> Gokul Balakrishnan
>> Senior Software Engineer,
>> WSO2, Inc. http://wso2.com
>> M +94 77 5935 789 | +44 7563 570502
>>
>>
>
>
> --
> *Anjana Fernando*
> Senior Technical Lead
> WSO2 Inc. | http://wso2.com
> lean . enterprise . middleware
>



-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919blog: **http://blog.afkham.org*
<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*
<http://twitter.com/afkham_azeez>
*linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Fwd: Implementation of Websockets for API Manager

[Afkham Azeez]

t;>>>>> a subprotocol handler (implemented in the synapse configuration of 
>>>>>> inbound
>>>>>> endpoint given above) by which mediation can be done to the message flow.
>>>>>> But the subprotocol is executed only when websocket frames are passing, 
>>>>>> but
>>>>>> not when the initial handshake is performed which is a FullHttpRequest.
>>>>>> Handshake is a function performed when the client and sever agrees to
>>>>>> upgrade its connection to a websocket connection to establish a full 
>>>>>> duplex
>>>>>> message flow, which is the best instance to perform authorization.
>>>>>> In this scenario,because we don't have an extension to implement the
>>>>>> authorization at the handshake, it is difficult to execute OAUTH 2.0 
>>>>>> which
>>>>>> is used to authorize the access to APIs. Therefore we would need an
>>>>>> extension point to execute custom code for the above mentioned purpose.
>>>>>>
>>>>>> @ESB Team, do you think that providing a mechanism to extend the
>>>>> handshake phase of the channel is a valuable addition? If yes, shall we
>>>>> start working on this? The objective of this is to do OAuth authentication
>>>>> during the handshake phase.
>>>>>
>>>>>>
>>>>>> --
>>>>>> *Arshardh Ifthikar*
>>>>>> Trainee Software Engineer
>>>>>> WSO2, Inc.
>>>>>> Mobile: +94719806525
>>>>>>
>>>>>> ___
>>>>>> Architecture mailing list
>>>>>> Architecture@wso2.org
>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Nuwan Dias
>>>>>
>>>>> Software Architect - WSO2, Inc. http://wso2.com
>>>>> email : nuw...@wso2.com
>>>>> Phone : +94 777 775 729
>>>>>
>>>>> ___
>>>>> Architecture mailing list
>>>>> Architecture@wso2.org
>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> *Shafreen*
>>>> Software Engineer
>>>> WSO2 Inc
>>>> Mobile : 077-556-395-1
>>>>
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> Nuwan Dias
>>>
>>> Software Architect - WSO2, Inc. http://wso2.com
>>> email : nuw...@wso2.com
>>> Phone : +94 777 775 729
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>>
>> *Sanjeewa Malalgoda*
>> WSO2 Inc.
>> Mobile : +94713068779
>>
>> <http://sanjeewamalalgoda.blogspot.com/>blog
>> :http://sanjeewamalalgoda.blogspot.com/
>> <http://sanjeewamalalgoda.blogspot.com/>
>>
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Isuru Udana*
> Technical Lead
> WSO2 Inc.; http://wso2.com
> email: isu...@wso2.com cell: +94 77 3791887
> blog: http://mytecheye.blogspot.com/
>



-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919blog: **http://blog.afkham.org*
<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*
<http://twitter.com/afkham_azeez>
*linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] How can we improve our profiles story?

[Afkham Azeez]

We proposed an idea to build a pack based on a profile. That will contain
only the essential stuff. So rather than starting up a runtime and then
loading a profile, you build a pack that contains the bare minimum stuff
required. Perhaps we can have a descriptor which describes what non-OSGi
stuff are required for a profile and we can combine that with the OSGi
bundles.info to figure out exactly what is needed. Can someone in the
kernel team do a quick PoC?

On Thu, Sep 22, 2016 at 11:26 AM, Srinath Perera  wrote:

> Smaeera, are these things we can fix?
>
> --Srinath
>
> On Thu, Sep 22, 2016 at 11:23 AM, Nuwan Dias  wrote:
>
>> Hi,
>>
>> This is to raise some concerns over the current server profiles. Although
>> we are able to control the bundles which are loaded to the runtime based on
>> the -Dprofile parameter, we still lack the ability of removing files and
>> modifying configuration files when the server starts on a profile. And this
>> is forcing us to start unnecessary bundles at startup. Let me explain...
>>
>> API Manager has both webapps and a gateway in its distribution. The
>> synapse bundles are only required in the Gateway profiles. However since
>> the axis2.xml file of API Manager defines the http transport senders and
>> receivers based on the Synapse passthrough senders and receivers, the axis2
>> engine will try to load the synapse classes on startup. Ideally if we were
>> able to modify the axis2.xml on the Publisher, Store and Key Manager
>> profiles and replace the passthrough senders and receivers with our
>> standard http senders and receivers, we could avoid loading the synapse
>> bundles on the Publisher, Store and Key Manager.
>>
>> The same problem occurs for registry indexers and handlers. Since the
>> registry indexers and handlers are configured on the registry.xml, even
>> though these are only required in the publisher and store profiles, these
>> bundles will be activated and running even on the Gateway, Key Manager and
>> Traffic Manager. So unless we modify the registry.xml on those nodes
>> manually, we can't stop those bundles from running.
>>
>> Another problem we're facing is the inability to remove webapps. Since
>> all webapps in the repository/deployment/server/webapps and
>> repository/deployment/server/jaggeryapps are deployed into the runtime,
>> unless we remove these webapps manually there is no other way to stop them
>> from being deployed in unrelated profiles.
>>
>> I heard there is a discussion to bind a profile to a container. Which
>> would solve these problems. However it still won't help the "non-container"
>> deployments. Are there ways to overcome the above mentioned limitations and
>> enhance the efficiency of our profiles?
>>
>> Thanks,
>> NuwanD.
>>
>> --
>> Nuwan Dias
>>
>> Software Architect - WSO2, Inc. http://wso2.com
>> email : nuw...@wso2.com
>> Phone : +94 777 775 729
>>
>
>
>
> --
> 
> Srinath Perera, Ph.D.
>http://people.apache.org/~hemapani/
>http://srinathsview.blogspot.com/
>



-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919blog: **http://blog.afkham.org*
<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*
<http://twitter.com/afkham_azeez>
*linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Store framework for C5 based Products

[Afkham Azeez]

On Wed, Sep 28, 2016 at 3:27 PM, Chathura Ekanayake 
wrote:

> If we are not storing trivial artifacts, it is very difficult to use a
> common UI for store and especially for publisher. If a store framework is
> used, we end up extending it and in many situations it can become more
> complex than developing a new UI. Therefore, I agree with Nuwan and
> SajithAR that we should focus on reusable UIs only for parts that can be
> used as it is, or with minimal modifications such as login, user
> management, etc.
>
>
+1
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] How can we improve our profiles story?

[Afkham Azeez]

At runtime, there should be profile specific packs shouldn't have anything
extra other than the bear minimum. This is to make it container friendly as
well.

On Tue, Oct 4, 2016 at 5:27 PM, Muhammed Shariq  wrote:

> Hi folks,
>
> I had a chat with Sameera and Jayanga on how we can improve support for
> managing configurations for a particular profile.
>
> We were discussing the possibility of extending the ConfigResolver [1]
> concept to manage profile specific configurations. With ConfigResolver, we
> have the ability to override certain configurations using the
> deployment.properties file, this way we only need modify a single file to
> override configurations scattered in different files.
>
> We are looking into the possibility of using the ConfigResolver approach
> to handle configs related to a specific profile as well. The idea is to
> have a profile specific deployment.properties file where we can specify the
> configs related to that particular profile. This way we can avoid
> duplicating the same config file and parameteriz values using the
> properties file.
>
> If we build a pack specific to a particular profile, this might create
> complication for the simplest scenario where a user wants to simply extract
> the distribution and try it out. With profile specific distributions, users
> will have to deal with multiple distributions (configuring offsets etc)
> even to try out a product which is cumbersome.
>
> So I feel, having a per profile properties is a feasible mechanism to
> define profile specify configs. Shall we go ahead with this approach?
>
> Any concerns, thoughts?
>
> [1] - [Architecture] [C5] Adding deployment.properties file to override
> configurations in components
> [2] - [C5] Less configuration elements with meaningful defaults
>
> On Mon, Oct 3, 2016 at 5:11 PM, Sameera Jayasoma  wrote:
>
>> Hi All,
>>
>> We can categorize all the files which need to be handled by profiles into
>> three groups.
>>
>>
>> *1) OSGi repository *
>>
>>- *Location:* repository/components
>>- *Description:* Contains all the OSGi bundles, dropins artifacts and
>>other required files. This repository is already organized into multiple
>>profiles(if any).
>>
>>
>> *2) Config repository*
>>
>>- *Location:* repository/conf
>>- *Description: Contains configuration files of the products. We need
>>to figure out a way handle profile specific configuration files.*
>>
>>
>> *3) Artifact repository*
>>
>>- *Location*: repository/deployment
>>- *Description*: Contains deployment artifacts of the product. We
>>need to figure out a way to handle profile specific deployment artifacts.
>>
>>
>> Shariq from the platform team will work on this.
>>
>> Thanks,
>> Sameera.
>>
>> On Fri, Sep 23, 2016 at 3:18 PM, Nuwan Dias  wrote:
>>
>>>
>>>
>>> On Fri, Sep 23, 2016 at 2:38 PM, Srinath Perera 
>>> wrote:
>>>
>>>> I think this happen with ESB NIO transport and Servelt transport for
>>>> webapps. ( Nuwan, is there other examples?).
>>>>
>>>
>>> In the regsitry.xml, we configure the indexers and handlers. These again
>>> are only required in certain profiles. There are also some configs in the
>>> api-manager.xml which only makes sense to enable in certain profiles.
>>>
>>>>
>>>> On Fri, Sep 23, 2016 at 9:42 AM, Kishanthan Thangarajah <
>>>> kishant...@wso2.com> wrote:
>>>>
>>>>> Current issue is that all bundles and artifacts (conf files, webapps)
>>>>> are common to the server which are shared among all the profiles. We don't
>>>>> have a way to delete and modify them when starting up a profile.
>>>>>
>>>>> One other option is we could pack everything (profile specific
>>>>> artifacts) in the base distribution and provide a build script (ant) which
>>>>> create profile specific runtime a.
>>>>>
>>>>> We will check for the other alternatives along with this PoC and see.
>>>>>
>>>>> On Thu, Sep 22, 2016 at 12:27 PM, Afkham Azeez  wrote:
>>>>>
>>>>>> We proposed an idea to build a pack based on a profile. That will
>>>>>> contain only the essential stuff. So rather than starting up a runtime 
>>>>>> and
>>>>>> then loading a profile, you build a pack that contains the bare
>>>>>> minimum stuff required. Perhaps we can hav

Re: [Architecture] How can we improve our profiles story?

[Afkham Azeez]

> provide a script / tool to create the bear minimum pack at runtime.
>>>>
>>>> If we go ahead with Option-1, then we will be creating multiple
>>>> distributions for a single product so a product like API-M will have many
>>>> different distributions. This I feel will make the simple case too
>>>> complicated, specially for a user trying to get started.
>>>>
>>>> With Option-2, we can still have the default profile as it is for the
>>>> simplest case, but provide users the ability to create profile specific
>>>> distributions for larger deployments. Users can then use these profile
>>>> specific distributions to create their images.
>>>>
>>>> In both cases, I feel we are moving away from using profiles as we used
>>>> to use them since we are creating a pack with only the required jars and
>>>> artifacts.
>>>>
>>>> Considering these factors, should we look to creating only the
>>>> container friendly bear minimum distribution (Option-1) or provide the
>>>> ability to a create profile specific pack from the default distribution?
>>>>
>>>>
>>>> On Wed, Oct 5, 2016 at 9:03 AM, Lakmal Warusawithana 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Oct 4, 2016 at 5:39 PM, Afkham Azeez  wrote:
>>>>>
>>>>>> At runtime, there should be profile specific packs shouldn't have
>>>>>> anything extra other than the bear minimum. This is to make it container
>>>>>> friendly as well.
>>>>>>
>>>>>
>>>>> Yes, reducing image size is critical to support container native
>>>>> architecture.
>>>>>
>>>>>
>>>>>>
>>>>>> On Tue, Oct 4, 2016 at 5:27 PM, Muhammed Shariq 
>>>>>> wrote:
>>>>>>
>>>>>>> Hi folks,
>>>>>>>
>>>>>>> I had a chat with Sameera and Jayanga on how we can improve support
>>>>>>> for managing configurations for a particular profile.
>>>>>>>
>>>>>>> We were discussing the possibility of extending the ConfigResolver
>>>>>>> [1] concept to manage profile specific configurations. With 
>>>>>>> ConfigResolver,
>>>>>>> we have the ability to override certain configurations using the
>>>>>>> deployment.properties file, this way we only need modify a single file 
>>>>>>> to
>>>>>>> override configurations scattered in different files.
>>>>>>>
>>>>>>> We are looking into the possibility of using the ConfigResolver
>>>>>>> approach to handle configs related to a specific profile as well. The 
>>>>>>> idea
>>>>>>> is to have a profile specific deployment.properties file where we can
>>>>>>> specify the configs related to that particular profile. This way we can
>>>>>>> avoid duplicating the same config file and parameteriz values using the
>>>>>>> properties file.
>>>>>>>
>>>>>>> If we build a pack specific to a particular profile, this might
>>>>>>> create complication for the simplest scenario where a user wants to 
>>>>>>> simply
>>>>>>> extract the distribution and try it out. With profile specific
>>>>>>> distributions, users will have to deal with multiple distributions
>>>>>>> (configuring offsets etc) even to try out a product which is cumbersome.
>>>>>>>
>>>>>>> So I feel, having a per profile properties is a feasible mechanism
>>>>>>> to define profile specify configs. Shall we go ahead with this approach?
>>>>>>>
>>>>>>> Any concerns, thoughts?
>>>>>>>
>>>>>>> [1] - [Architecture] [C5] Adding deployment.properties file to
>>>>>>> override configurations in components
>>>>>>> [2] - [C5] Less configuration elements with meaningful defaults
>>>>>>>
>>>>>>> On Mon, Oct 3, 2016 at 5:11 PM, Sameera Jayasoma 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> We can cate

Re: [Architecture] Multiple profile support for C5 based products.

[Afkham Azeez]

Please note that during a discussion this week, we decided that instead of
all carbon servers running on the same ports, each of the 5 products will
have their own well known ports. For example, APIM GW port will be 8084
(just an example). So while we would still have portOffset support, we
won't need to specify the offset when running multiple products on the same
machine and they will be able to discover each other on these well known
ports.

On Wed, Oct 12, 2016 at 6:29 PM, Nuwan Dias  wrote:

> Do we really need multi-profile support (at an osgi level) on C5? What if
> we have separate dedicated runtimes per profile? Which means that we have a
> gateway runtime, store runtime, etc. within the same distribution? Each
> will run on its own port, maybe using offsets by default (no need to worry
> about that if each profile is a container).
>
> Also if we have profiles, do we also have a global profile which runs all
> components in one? I doubt we'll be able to achieve the target of 1 to 2
> sec startup time if we do that.
>
> Thanks,
> NuwanD.
>
> On Wed, Oct 12, 2016 at 3:40 PM, Muhammed Shariq  wrote:
>
>> With regards to the discussion on improving some of the limitations in
>> the our current product profiles support [1], we had a discussion to
>> rethink how we can improve the support for running different profiles in C5.
>>
>> Participants - Lakmal, Azeez, Imesh, Kishanthan, Jayanga, Chandana, Rohan
>>
>> *Limitations with the current approach*
>>
>> - We only consider the bundles.info and load the necessary bundles,
>> however there might be certain configs and deployment artifacts that's not
>> required
>> - Some functionalities that aren't required for certain profiles are
>> enabled (e.g. transports)
>> - Distribution size is not optimal for container native architecture
>>
>> *Suggestion for profile support in C5*
>>
>> Considering the above limitation, we decided on building a profile
>> specific distribution from the base distribution. The base distribution
>> will pack all artifacts and also profile specific descriptors
>>
>> If there are any configs specific to a profile, those configs can be
>> changed using the deployment.properties file. The base distribution will
>> have deployment.properties file specific to the profiles, that way we don't
>> have to duplicate any config files.
>>
>> During the runtime, each profile will run as an independent process - for
>> this, we'll be moving away from default 9763/9443 ports, instead each
>> product will have an assigned port range.
>>
>> We will provide a tool that will look into the profile descriptors and
>> build the bare minimum runtime corresponding to the profile. This tool will
>> copy the required bundles, config files etc by looking into the meta info.
>> We can use the same tool to start the runtimes as well.
>>
>> The directory structure of the base distribution will be something like;
>>
>> wso2-am
>> |-- bin
>> |-- osgi
>>  |-- plugins
>> |-- conf
>> |-- profiles
>>  |-- gateway
>>   |-- metadata.yaml
>>   |-- deployment.properties
>>  |-- km
>>   |-- metadata.yaml
>>   |-- deployment.properties
>> |-- *runtime* --> wiill be created by the tool
>>  |-- *wso2-am-gateway*
>>  |-- *wso2-am-km*
>>
>> As shown in the folder structure, the tool will create the profile
>> specific runtime by reading the bundles.info, metadata file etc. In the
>> metadata.yaml file, we can specify what are the config files and other
>> resources needed for that particular profile. So a given runtime will only
>> have the minimum required jars and configs.
>>
>> Additionally, the tool provides the option to create docker-compose yaml
>> that would take the created runtimes and deploy it in containers.
>>
>> We have started implementing the tool, please share your thoughts /
>> suggestions.
>>
>> [1] - [Architecture] How can we improve our profiles story?
>>
>> --
>> Thanks,
>> Shariq
>> Associate Technical Lead
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Nuwan Dias
>
> Software Architect - WSO2, Inc. http://wso2.com
> email : nuw...@wso2.com
> Phone : +94 777 775 729
>



-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919blog: **http://blog.afkham.org*
<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*
<http://twitter.com/afkham_azeez>
*linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Configuration files in C5

[Afkham Azeez]

I think Imesh's suggestion merges all the config files and complicates
stuff a lot. With the deployment.properties file we are including only the
bits that most users will be concerned about and will provide a simple way
to configure such stuff.

On Fri, Oct 14, 2016 at 9:50 AM, Isuru Perera  wrote:

> +1 for using a YAML file instead of a properties file.
>
> On Fri, Oct 14, 2016 at 8:45 AM, Imesh Gunaratne  wrote:
>
>> I would like to propose to use a single YAML file for each distribution
>> (product/profile) to make the configuration process easier.
>>
>> I understand that we are trying to do something similar using a
>> properties file (by overriding configurations in separate files), however
>> IMO a properties file might not suite well for this purpose. A YAML file or
>> any other type of a file which is more readable and designed for managing
>> hierarchical data structures would work well. More importantly having a
>> single configuration file would make the configuration process more simpler
>> and clean. WDYT?
>>
>> Thanks
>>
>>
>> On Thursday, October 13, 2016, Sidath Weerasinghe 
>> wrote:
>>
>>> Hi Jayanga,
>>>
>>> What are the most frequently changing configurations in C5 which are
>>> going to store in the deployment.properties" file ?
>>>
>>> On Thu, Oct 13, 2016 at 5:07 PM, Jayanga Dissanayake 
>>> wrote:
>>>
>>>> Hi All,
>>>>
>>>> With C5, we introduced "ConfigResolver" which enhances the user
>>>> experience in changing configuration values. With the previous C4x
>>>> approach, users had to know where the configuration files are and to,
>>>> change several configuration files to get the product working in some
>>>> scenarios.
>>>>
>>>> With "ConfigResolver" it allows us to have more frequently changing
>>>> configurations in one location "deployment.properties" file.
>>>>
>>>> A product has set of configurations that are needed to be changed in
>>>> the deployments and there are some other configurations that we don't
>>>> change unless there is a complex situation. Hence, ideally,
>>>> deployment.properties file should contain only the configurations that are
>>>> frequently used and can add more entries if a requirement arise.
>>>>
>>>> But with the requirements coming in with the "profile" support [1]. we
>>>> have to rethink the way config resolver handle the configuration files.
>>>>
>>>> eg:
>>>> 1. We need to enable indexing in API store and publisher, not in other
>>>> profiles.
>>>> 2. Enabling certain handlers in particular profiles.
>>>>
>>>> At present, there is no configuration to enable/disable these features.
>>>> We have to rethink the way we define configurations in features in future.
>>>> We have to have a way to enable/disable certain features so that those
>>>> could be disabled in certain profiles.
>>>>
>>>> Any idea/questions/clarifications are highly appreciated as it will
>>>> help to model the new configurations story in C5.
>>>>
>>>> [1] "Multiple profile support for C5 based products."
>>>>
>>>> Thanks,
>>>> *Jayanga Dissanayake*
>>>> Associate Technical Lead
>>>> WSO2 Inc. - http://wso2.com/
>>>> lean . enterprise . middleware
>>>> email: jaya...@wso2.com
>>>> mobile: +94772207259
>>>> <http://wso2.com/signature>
>>>>
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> Thank You,
>>> Best Regards,
>>>
>>> Sidath Weerasinghe
>>>
>>>
>>> *Intern*
>>>
>>> *WSO2, Inc. *
>>>
>>> *lean . enterprise . middleware *
>>>
>>>
>>> *Mobile: +94719802550 <%2B94719802550>*
>>>
>>> *Email: *sid...@wso2.com
>>>
>>> Blog: https://medium.com/@sidath
>>>
>>> Linkedin: https://lk.linkedin.com/in/sidathweerasinghe
>>>
>>
>>
>> --
>> *Imesh Gunaratne*
>> Software Architect
>> WSO2 Inc: http://wso2.com
>> T: +94 11 214 5345 M:

Re: [Architecture] test message

[Afkham Azeez]

Ack

On Sun, Oct 16, 2016 at 12:49 AM,  wrote:

> test message
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>



-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919blog: **http://blog.afkham.org*
<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*
<http://twitter.com/afkham_azeez>
*linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Carbon C5 - Server Configuration Model

[Afkham Azeez]

On Tue, Nov 22, 2016 at 10:19 AM, SajithAR Ariyarathna 
wrote:

> Hi Danesh,
>
> Do we really need the @Ignore annotation? IMO, we can ignore frields wich
> are not marked with @Element annotation, thus we don't need a separate
> annotation.
>

@Element is optional. By default all fields will become config elements.
That is how it works in popular frameworks such as JAXB. So we are giving a
simple way to specify that some fileds shouldn't become config elements.


>
> Thanks.
>
> On Mon, Nov 21, 2016 at 11:32 PM, Danesh Kuruppu  wrote:
>
>> Hi all,
>>
>> In Carbon C5, we are going to introduce new global configuration model
>> where we have only one configuration file for all server configurations.
>> So that user have to maintain only one config file for a server.
>>
>> With New Configuration Model,
>>
>>- Global configuration file (deployment.yaml) includes minimal sets
>>of configurations which need to override very often by default (e.g: 
>> server
>>ports etc).
>>- All user settable configurations must have default values and they
>>are burnt into compile codes.
>>- Any default configuration can overridden by adding the particular
>>configuration to the global configuration file(deployment.yaml).
>>- Defining all configurations in the configuration file in not
>>required. add only if we need to override the default value.
>>- If configurations are not specified in the configuration file,
>>values defined in the bean class will apply by default.
>>
>> In global configuration file (deployment.yaml),
>>
>>- Each component will have their own configurations with a unique
>>namespace (e.g: wso2.carbon, wso2.transports.netty etc) and it will be a
>>fragment of deployment.yaml file. Please find the sample file below.
>>- At runtime, the relevant config bean will be generated by
>>overriding the default values specified in bean class with values 
>> mentioned
>>in deployment.yaml file.
>>
>> Sample file looks like,
>>
>>   # Carbon Configuration Parameters
>> wso2.carbon:
>>   id: carbon-kernel
>>   version: 5.2.0-SNAPSHOT
>>   ports:
>> offset: 0
>>   ...
>>
>>   # Netty Transport Configurations
>> wso2.transports.netty:
>>   listeners:
>> - id: msf4j-http
>>   host: 127.0.0.1
>>   port: 8080
>>   bossThreadPoolSize: 2
>>   workerThreadPoolSize: 250
>>   parameters:
>> - name: "executor.workerpool.size"
>>   value: 60
>>
>> ...
>>
>> Along with the above design, we are going to introduce new annotation
>> model to the configuration beans. So each component will have its
>> configuration defined as one or more Java beans annotated with the
>> following annotations
>>
>>- *org.wso2.carbon.kernel.annotations.Configuration* - *Class level
>>annotation, This corresponds to a configuration bean to be used by a
>>component*
>>- *org.wso2.carbon.kernel.annotations.Element* - *Field level
>>annotation, This corresponds to a fields of the class*
>>- *org.wso2.carbon.kernel.annotations.Ignore* - *Field level
>>annotation, This is to specify that field needs to be ignored when the
>>configuration is generated*
>>
>> Sample bean class looks like,
>>
>> @Configuration(namespace = "wso2.carbon", description = "Carbon 
>> Configuration Parameters")
>> public class CarbonConfiguration {
>>
>> @Element(description = "value to uniquely identify a server", required = 
>> true)
>> private String id = "carbon-kernel";
>>
>> @Element(description = "server name")
>> private String name = "WSO2 Carbon Kernel";
>>
>> @Element(description = "server version")
>> private String version = "5.2.0";
>>
>> @Ignore
>> private String tenant = Constants.DEFAULT_TENANT;
>>
>> ...
>>
>> }
>>
>> So we are going to generate the relevant segment of the configuration
>> file(for documentation purposes) automatically at compile time by reading
>> above annotations and default values.
>>
>> If anyone needs to override the default value, He needs to copy the
>> particular segment of the configuration to the deployment.yaml and change
>> the value.
>>
>> Appreciate your input on this.
>>
>> Thanks
>> --
>>
>> *Danesh Ku

Re: [Architecture] [Dev] [C5] MSF4J Interceptors need to be configurable.

[Afkham Azeez]

How about supporting JAXRS filters?

On Wed, Dec 7, 2016 at 12:52 PM, Thusitha Thilina Dayaratne <
thusit...@wso2.com> wrote:

> Hi Ishara,
>
> As you have mentioned, with the current architecture we can't set the
> specific interceptor for a particular service but rather to all services in
> the registry. And also if there are multiple interceptors and one
> interceptor returns false from its' preCaall then the invocation chain will
> not continue further.
>
> IMHO we have few options
>
>- We can implement a way to register specific interceptors to specific
>services
>- We can support JAX-RS Filters
>- We can provide a way to skip some interceptors for specific services
>
> @Azeez WDYT?
>
> Thanks
> Thusitha
>
>
> On Wed, Dec 7, 2016 at 10:56 AM, Ishara Cooray  wrote:
>
>> HI,
>>
>> We are using MSF4J interceptor for securing REST APIs in API Manager. [1]
>> As for now Interceptor registration happens at the class level @Component
>> annotation as below.
>>
>> @Component(
>> name = "org.wso2.carbon.apimgt.rest.a
>> pi.common.interceptors.OAUTH2SecurityInterceptor",
>> service = Interceptor.class,
>> immediate = true
>> )
>> The limitations here are
>>
>>1. it is not possible to have more than one interceptor that will
>>dynamically pick when an api call is received(Because the order matters 
>> and
>>we are not certain which interceptor will take into effect ).
>>2. We cannot explicitly configure to use Custom interceptors because
>>of the above[1] reason.
>>
>> Do we have any plans for these limitations?
>>
>> Thanks & Regards,
>> Ishara Cooray
>> Senior Software Engineer
>> Mobile : +9477 262 9512 <+94%2077%20262%209512>
>> WSO2, Inc. | http://wso2.com/
>> Lean . Enterprise . Middleware
>>
>>
>> ___
>> Dev mailing list
>> d...@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Thusitha Dayaratne
> Software Engineer
> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>
> Mobile  +94712756809 <071%20275%206809>
> Blog  alokayasoya.blogspot.com
> Abouthttp://about.me/thusithathilina
> <http://wso2.com/signature>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Afkham Azeez*
Senior Director, Platform Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919blog: **http://blog.afkham.org*
<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*
<http://twitter.com/afkham_azeez>
*linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [C5] MSF4J Interceptors need to be configurable.

[Afkham Azeez]

On Wed, Dec 7, 2016 at 5:17 PM, Ishara Cooray  wrote:

> Hi Thilina,
>
> And also if there are multiple interceptors and one interceptor returns
> false from its' preCaall then the invocation chain will not continue
> further.
>
> So Is this implies if preCall returns 'true' then the invocation chain
> will continue further?
>

Yes


> If that is the case we can return true in our overridden preCall method so
> that it goes to next Interceptor.
>
>
> Thanks & Regards,
> Ishara Cooray
> Senior Software Engineer
> Mobile : +9477 262 9512 <077%20262%209512>
> WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> On Wed, Dec 7, 2016 at 2:33 PM, Afkham Azeez  wrote:
>
>> How about supporting JAXRS filters?
>>
>> On Wed, Dec 7, 2016 at 12:52 PM, Thusitha Thilina Dayaratne <
>> thusit...@wso2.com> wrote:
>>
>>> Hi Ishara,
>>>
>>> As you have mentioned, with the current architecture we can't set the
>>> specific interceptor for a particular service but rather to all services in
>>> the registry. And also if there are multiple interceptors and one
>>> interceptor returns false from its' preCaall then the invocation chain will
>>> not continue further.
>>>
>>> IMHO we have few options
>>>
>>>- We can implement a way to register specific interceptors to
>>>specific services
>>>- We can support JAX-RS Filters
>>>- We can provide a way to skip some interceptors for specific
>>>services
>>>
>>> @Azeez WDYT?
>>>
>>> Thanks
>>> Thusitha
>>>
>>>
>>> On Wed, Dec 7, 2016 at 10:56 AM, Ishara Cooray  wrote:
>>>
>>>> HI,
>>>>
>>>> We are using MSF4J interceptor for securing REST APIs in API Manager.
>>>> [1] As for now Interceptor registration happens at the class level
>>>> @Component annotation as below.
>>>>
>>>> @Component(
>>>> name = "org.wso2.carbon.apimgt.rest.a
>>>> pi.common.interceptors.OAUTH2SecurityInterceptor",
>>>> service = Interceptor.class,
>>>> immediate = true
>>>> )
>>>> The limitations here are
>>>>
>>>>1. it is not possible to have more than one interceptor that will
>>>>dynamically pick when an api call is received(Because the order matters 
>>>> and
>>>>we are not certain which interceptor will take into effect ).
>>>>2. We cannot explicitly configure to use Custom interceptors
>>>>because of the above[1] reason.
>>>>
>>>> Do we have any plans for these limitations?
>>>>
>>>> Thanks & Regards,
>>>> Ishara Cooray
>>>> Senior Software Engineer
>>>> Mobile : +9477 262 9512 <+94%2077%20262%209512>
>>>> WSO2, Inc. | http://wso2.com/
>>>> Lean . Enterprise . Middleware
>>>>
>>>>
>>>> ___
>>>> Dev mailing list
>>>> d...@wso2.org
>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>
>>>>
>>>
>>>
>>> --
>>> Thusitha Dayaratne
>>> Software Engineer
>>> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>>>
>>> Mobile  +94712756809 <071%20275%206809>
>>> Blog  alokayasoya.blogspot.com
>>> Abouthttp://about.me/thusithathilina
>>> <http://wso2.com/signature>
>>>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> *Afkham Azeez*
>> Senior Director, Platform Architecture; WSO2, Inc.; http://wso2.com
>> Member; Apache Software Foundation; http://www.apache.org/
>> * <http://www.apache.org/>*
>> *email: **az...@wso2.com* 
>> * cell: +94 77 3320919 <+94%2077%20332%200919>blog: *
>> *http://blog.afkham.org* <http://blog.afkham.org>
>> *twitter: **http://twitter.com/afkham_azeez*
>> <http://twitter.com/afkham_azeez>
>> *linked-in: **http://lk.linkedin.com/in/afkhamazeez
>> <http://lk.linkedin.com/in/afkhamazeez>*
>>
>> *Lean . Enterprise . Middleware*
>>
>
>


-- 
*Afkham Azeez*
Senior Director, Platform Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919blog: **http://blog.afkham.org*
<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*
<http://twitter.com/afkham_azeez>
*linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5] [Carbon-Feature-Plugin] Dynamic Creation of carbon.product via a Template

[Afkham Azeez]

Sounds good. We can simply rely on the pom and not duplicate the version in
different files.

On Fri, Jan 20, 2017 at 3:06 PM, Dilan Udara Ariyaratne 
wrote:

> Hi Folks,
>
> In the process of building C5, we currently require carbon.product for the
> following goals.
> [1] publish-product
> [2] generate-runtime
>
> This file maintains current version of the carbon kernel to be utilized by
> "carbon-feature-plugin" in the build process.
> Keeping this value in carbon.product prevents the kernel from been
> auto-released as it requires manual intervention to bump
> version values as necessary during the release process.
>
> In order to solve this issue, we are currently in the process of improving
> Carbon-Feature-Plugin to dynamically create this file during build time
> using
> a template where the necessary version value information is read from
> corresponding distribution pom file.
>
> In order to support backward compatibility, we will still maintain the
> original approach of keeping a carbon.product file somewhere appropriate
> in the distribution folder and read it accordingly when
>  tag is present in the pom file.
>
> In the meantime, as the way to go forward, we will introduce the following.
>
> Carbon-Feature-Plugin will be updated to read version and other optional
> values that were originally persisted in the file, from the pom itself.
> After reading these values, plugin will dynamically create the
> carbon.product which will then be taken into reference by underlying
> eclipse.tycho plugin as in the usual way of execution.
>
> WDYT ?
>
> Thank You.
>
> *Dilan U. Ariyaratne*
> Senior Software Engineer
> WSO2 Inc. <http://wso2.com/>
> Mobile: +94766405580 <%2B94766405580>
> lean . enterprise . middleware
>
>
> _______
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Afkham Azeez*
Senior Director, Platform Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919blog: **http://blog.afkham.org*
<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*
<http://twitter.com/afkham_azeez>
*linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5] [Carbon-Feature-Plugin] Dynamic Creation of carbon.product via a Template

[Afkham Azeez]

I would suggest totally getting rid of it.

On Fri, Jan 20, 2017 at 5:24 PM, KasunG Gajasinghe  wrote:

>
> +1. carbon.product file hasn't really been used by the products. So, +1
> to make it optional.
>
> On Fri, Jan 20, 2017 at 3:06 PM, Dilan Udara Ariyaratne 
> wrote:
>
>> Hi Folks,
>>
>> In the process of building C5, we currently require carbon.product for
>> the following goals.
>> [1] publish-product
>> [2] generate-runtime
>>
>> This file maintains current version of the carbon kernel to be utilized
>> by "carbon-feature-plugin" in the build process.
>> Keeping this value in carbon.product prevents the kernel from been
>> auto-released as it requires manual intervention to bump
>> version values as necessary during the release process.
>>
>> In order to solve this issue, we are currently in the process of
>> improving Carbon-Feature-Plugin to dynamically create this file during
>> build time using
>> a template where the necessary version value information is read from
>> corresponding distribution pom file.
>>
>> In order to support backward compatibility, we will still maintain the
>> original approach of keeping a carbon.product file somewhere appropriate
>> in the distribution folder and read it accordingly when
>>  tag is present in the pom file.
>>
>> In the meantime, as the way to go forward, we will introduce the
>> following.
>>
>> Carbon-Feature-Plugin will be updated to read version and other optional
>> values that were originally persisted in the file, from the pom itself.
>> After reading these values, plugin will dynamically create the
>> carbon.product which will then be taken into reference by underlying
>> eclipse.tycho plugin as in the usual way of execution.
>>
>> WDYT ?
>>
>> Thank You.
>>
>> *Dilan U. Ariyaratne*
>> Senior Software Engineer
>> WSO2 Inc. <http://wso2.com/>
>> Mobile: +94766405580 <%2B94766405580>
>> lean . enterprise . middleware
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
>
> *Kasun Gajasinghe*Associate Technical Lead, WSO2 Inc.
> email: kasung AT spamfree wso2.com
> linked-in: http://lk.linkedin.com/in/gajasinghe
> blog: http://kasunbg.org
> phone: +1 650-745-4499 <+1%20650-745-4499>, 77 678 0813
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Afkham Azeez*
Senior Director, Platform Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919blog: **http://blog.afkham.org*
<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*
<http://twitter.com/afkham_azeez>
*linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5] [Carbon-Feature-Plugin] Dynamic Creation of carbon.product via a Template

[Afkham Azeez]

Yeah that approach sounds good

On Jan 27, 2017 4:30 PM, "Dilan Udara Ariyaratne"  wrote:

>
>
> *Dilan U. Ariyaratne*
> Senior Software Engineer
> WSO2 Inc. <http://wso2.com/>
> Mobile: +94766405580 <%2B94766405580>
> lean . enterprise . middleware
>
>
> On Thu, Jan 26, 2017 at 10:06 AM, Kishanthan Thangarajah <
> kishant...@wso2.com> wrote:
>
>>
>>
>> On Mon, Jan 23, 2017 at 11:49 AM, Dilan Udara Ariyaratne > > wrote:
>>
>>> Hi Azeez,
>>>
>>> Even with the pom based approach (as noted by Kishanthan), we do not
>>> have the luxury of totally getting rid of this file, carbon.product
>>>
>>
>> I believe this is only needed at product build time, so we do not need to
>> keep a file in the repo but only create the file during build time and then
>> delete it (or may be use the target directory so that it will be anyway
>> removed).
>>
> +1 to create the file at target directory during build time, I just tested
> the implementation and it works fine. So, in going forward, we can
> deprecate the static carbon.product file that exists in distribution folder
> of the repo.
>
>>
>> since both underlying, but external tycho and equinox launcher plug-ins
>>> used by our carbon-feature-plugin require this file as an input.
>>>
>>> So IMO, the only improvement that we can introduce here is supporting
>>> templated-dynamic-creation of the file at carbon-feature-plugin level
>>> using the standard carbon kernel version values available in the
>>> distribution pom.
>>>
>>> Thanks,
>>> Dilan.
>>>
>>> *Dilan U. Ariyaratne*
>>> Senior Software Engineer
>>> WSO2 Inc. <http://wso2.com/>
>>> Mobile: +94766405580 <%2B94766405580>
>>> lean . enterprise . middleware
>>>
>>>
>>> On Mon, Jan 23, 2017 at 7:33 AM, Kishanthan Thangarajah <
>>> kishant...@wso2.com> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Jan 20, 2017 at 5:57 PM, Afkham Azeez  wrote:
>>>>
>>>>> I would suggest totally getting rid of it.
>>>>>
>>>>
>>>> To maintain backward compatibility of the plugin, we need to have the
>>>> file based supported. But from next major release of the plugin, we can
>>>> remove the usage of this file and use the pom based approach only.
>>>>
>>>> Thanks,
>>>>
>>>>>
>>>>> On Fri, Jan 20, 2017 at 5:24 PM, KasunG Gajasinghe 
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> +1. carbon.product file hasn't really been used by the products. So,
>>>>>> +1 to make it optional.
>>>>>>
>>>>>> On Fri, Jan 20, 2017 at 3:06 PM, Dilan Udara Ariyaratne <
>>>>>> dil...@wso2.com> wrote:
>>>>>>
>>>>>>> Hi Folks,
>>>>>>>
>>>>>>> In the process of building C5, we currently require carbon.product
>>>>>>> for the following goals.
>>>>>>> [1] publish-product
>>>>>>> [2] generate-runtime
>>>>>>>
>>>>>>> This file maintains current version of the carbon kernel to be
>>>>>>> utilized by "carbon-feature-plugin" in the build process.
>>>>>>> Keeping this value in carbon.product prevents the kernel from been
>>>>>>> auto-released as it requires manual intervention to bump
>>>>>>> version values as necessary during the release process.
>>>>>>>
>>>>>>> In order to solve this issue, we are currently in the process of
>>>>>>> improving Carbon-Feature-Plugin to dynamically create this file during
>>>>>>> build time using
>>>>>>> a template where the necessary version value information is read
>>>>>>> from corresponding distribution pom file.
>>>>>>>
>>>>>>> In order to support backward compatibility, we will still maintain
>>>>>>> the original approach of keeping a carbon.product file somewhere
>>>>>>> appropriate
>>>>>>> in the distribution folder and read it accordingly when
>>>>>>>  tag is present in the pom file.
>>>>>>>
>>>>>>> In the meantime, as the way to go forward, we will introduce the
>&g

Re: [Architecture] Carbon C5 - Server Configuration Model

[Afkham Azeez]

This is out of the scope of the deployment.yaml processing framework Danesh
wrote. If you want to have default connectors or config, you can either
write a product-specific component which programmatically creates those, or
you can ship that in the product specific deployment.yaml.

On Thu, Feb 2, 2017 at 7:24 AM, Sagara Gunathunga  wrote:

>
>
> On Wed, Feb 1, 2017 at 11:11 PM, Danesh Kuruppu  wrote:
>
>> Hi Jayanga,
>>
>> it is defaulted to the component. any product which is using the
>> component will get the same default values. If a product need values other
>> than the default value, they have to override it in the deployment.yaml.
>> default values should be component related values, not related for the
>> specific product.
>>
>
> This is true in ideal cases but practically we have more complex use
> cases, taking the same example identity-mgt is a generic F/W kind of a
> component which allows to register/manage IdentityStore connectors and
> there is no component level default connector concept, it's just a
> registration/management capability, only in product level(IS) we ship
> default  IdentityStore connectors.  Here we have 2 options ..
>
> 1.) As there is no default connector in component level, all the products
> including IS has to provide default connectors  in  deployment.yaml, then
> this is not kind of value overridden and when number of such components
> increase default size of the deployment.yaml will increase which again
> result into deviate from original motivation of deployment.yaml.
>
>
> 2. ) In cases of components do not have default values we can hard cord
> default values according to the base product, in this way at least base
> product  can keep deployment.yaml clean.
>
> WDYT ?
>
>
> Thanks !
>
>
>>
>> Thanks
>> Danesh
>>
>> On Wed, Feb 1, 2017 at 3:58 AM, Jayanga Kaushalya 
>> wrote:
>>
>>> Hi,
>>>
>>> If we are hard-coding default values to the bean class, are those values
>>> should be default to the component or to the product which is
>>> (frequently) using that component ? If we use default values related to the
>>> product then we can use that values directly in the specific product and if
>>> some other product is using that component, they have to override it in the
>>> deployment.yaml. For example product-is is using component identity-mgt. So
>>> what should be the default values for the config files coming from
>>> identity-mgt component ? Are those should be defaulted to the product-is
>>> related values or to the component related values and product-is should
>>> always override them from deployment.yaml.
>>>
>>> Thanks!
>>>
>>> *Jayanga Kaushalya*
>>> Software Engineer
>>> Mobile: +94777860160 <+94%2077%20786%200160>
>>> WSO2 Inc. | http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> On Wed, Nov 30, 2016 at 10:57 AM, Danesh Kuruppu 
>>> wrote:
>>>
>>>> Hi Dilan,
>>>>
>>>> If all user-configurable properties are not readily available in the
>>>>> .yaml file by default, how would a user know which
>>>>> properties are configurable and which are not ?
>>>>>
>>>>
>>>> All the configurable properties and their default values will be
>>>> documented. We are going to create this config document automatically by
>>>> reading the config bean class (using maven plugin).
>>>> We need to decide whether we pack those config documents in the product
>>>> or add to central location (doc page etc)
>>>>
>>>> Thanks
>>>> --
>>>>
>>>> *Danesh Kuruppu*
>>>> Senior Software Engineer | WSO2
>>>>
>>>> Email: dan...@wso2.com
>>>> Mobile: +94 (77) 1690552 <+94%2077%20169%200552>
>>>> Web: WSO2 Inc <https://wso2.com/signature>
>>>>
>>>>
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>
>>
>> --
>>
>> *Danesh Kuruppu*
>> Senior Software Engineer | WSO2
>>
>> Email: dan...@wso2.com
>> Mobile: +94 (77) 1690552 <+94%2077%20169%200552>
>> Web: WSO2 Inc <https://wso2.com/signature>
>>
>>
>
>
> --
> Sagara Gunathunga
>
> Associate Director / Architect; WSO2, Inc.;  http://wso2.com
> V.P Apache Web Services;http://ws.apache.org/
> Linkedin; http://www.linkedin.com/in/ssagara
> Blog ;  http://ssagara.blogspot.com
>
>


-- 
*Afkham Azeez*
Senior Director, Platform Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919blog: **http://blog.afkham.org*
<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*
<http://twitter.com/afkham_azeez>
*linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Carbon C5 - Server Configuration Model

[Afkham Azeez]

Yes we need to do that.


On Thu, Feb 2, 2017 at 10:32 AM, Thusitha Thilina Dayaratne <
thusit...@wso2.com> wrote:

> Hi All,
>
> Since MSF4J supports non-OSGi mode, IMHO it would be great if we move this
> out from the carbon.core and create a separate top level component which
> will support both OSGi and standalone mode. Then we can use this to
> configure the executor pool, according to the new carbon transport
> architecture.
> WDYT?
>
> Thanks
> Thusitha
>
> On Thu, Feb 2, 2017 at 10:16 AM, Sagara Gunathunga 
> wrote:
>
>>
>> We (myself and Azeez) had a offline chat about this requirement, it seems
>> it would be much flexible for both users and product teams if
>> deployment.yaml processing framework can support 3 levels instead of 2 :
>> Component, Product, User
>>
>> Component level  : - Component author define default values within the
>> bean class if  'default values' concept is applicable.
>> Product level:-  Product team override component level default
>> values using 'defaults.yaml' file ( within the WSO2 file space )
>> User level :-  User can override component or product level
>> default values using deployment.yaml file
>>
>> The main advantage here is we can clearly separate responsibilities and
>> scope of each group and possible to ship deployment.yaml with absolutely
>> zero content.  This is the same concept suggested by Ruwan with few
>> modifications.
>>
>> Thanks !
>>
>> On Thu, Feb 2, 2017 at 9:36 AM, Afkham Azeez  wrote:
>>
>>> This is out of the scope of the deployment.yaml processing framework
>>> Danesh wrote. If you want to have default connectors or config, you can
>>> either write a product-specific component which programmatically creates
>>> those, or you can ship that in the product specific deployment.yaml.
>>>
>>> On Thu, Feb 2, 2017 at 7:24 AM, Sagara Gunathunga 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Feb 1, 2017 at 11:11 PM, Danesh Kuruppu 
>>>> wrote:
>>>>
>>>>> Hi Jayanga,
>>>>>
>>>>> it is defaulted to the component. any product which is using the
>>>>> component will get the same default values. If a product need values other
>>>>> than the default value, they have to override it in the deployment.yaml.
>>>>> default values should be component related values, not related for the
>>>>> specific product.
>>>>>
>>>>
>>>> This is true in ideal cases but practically we have more complex use
>>>> cases, taking the same example identity-mgt is a generic F/W kind of a
>>>> component which allows to register/manage IdentityStore connectors and
>>>> there is no component level default connector concept, it's just a
>>>> registration/management capability, only in product level(IS) we ship
>>>> default  IdentityStore connectors.  Here we have 2 options ..
>>>>
>>>> 1.) As there is no default connector in component level, all the
>>>> products including IS has to provide default connectors  in
>>>>  deployment.yaml, then this is not kind of value overridden and when number
>>>> of such components increase default size of the deployment.yaml will
>>>> increase which again result into deviate from original motivation of
>>>> deployment.yaml.
>>>>
>>>>
>>>> 2. ) In cases of components do not have default values we can hard cord
>>>> default values according to the base product, in this way at least base
>>>> product  can keep deployment.yaml clean.
>>>>
>>>> WDYT ?
>>>>
>>>>
>>>> Thanks !
>>>>
>>>>
>>>>>
>>>>> Thanks
>>>>> Danesh
>>>>>
>>>>> On Wed, Feb 1, 2017 at 3:58 AM, Jayanga Kaushalya 
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> If we are hard-coding default values to the bean class, are those
>>>>>> values should be default to the component or to the product which is
>>>>>> (frequently) using that component ? If we use default values related to 
>>>>>> the
>>>>>> product then we can use that values directly in the specific product and 
>>>>>> if
>>>>>> some other product is using that component, they have to override it i

Re: [Architecture] [APIM] [MSF4J] Reason for creating separate micro service for each path defined swagger

[Afkham Azeez]

gt; - Added microservice: org.wso2.carbon.apimgt.rest.
> api.store.PoliciesApi@50ba8085
> [2017-03-09 12:44:44,380]  INFO 
> {org.wso2.msf4j.internal.MicroservicesRegistryImpl}
> - Added microservice: org.wso2.carbon.apimgt.rest.
> api.store.PoliciesApi@50ba8085
> [2017-03-09 12:44:44,424]  INFO 
> {org.wso2.msf4j.internal.MicroservicesRegistryImpl}
> - Added microservice: org.wso2.carbon.apimgt.rest.
> api.store.SubscriptionsApi@18da9675
> [2017-03-09 12:44:44,474]  INFO 
> {org.wso2.msf4j.internal.MicroservicesRegistryImpl}
> - Added microservice: org.wso2.carbon.apimgt.rest.
> api.store.SubscriptionsApi@18da9675
> [2017-03-09 12:44:44,525]  INFO 
> {org.wso2.msf4j.internal.MicroservicesRegistryImpl}
> - Added microservice: org.wso2.carbon.apimgt.rest.
> api.store.TagsApi@1e835f96
> [2017-03-09 12:44:44,573]  INFO 
> {org.wso2.msf4j.internal.MicroservicesRegistryImpl}
> - Added microservice: org.wso2.carbon.apimgt.rest.
> api.store.TagsApi@1e835f96
> [2017-03-09 12:44:44,843]  INFO 
> {org.wso2.msf4j.internal.MicroservicesServerSC}
> - All microservices are available
> [2017-03-09 12:44:44,844]  INFO {org.wso2.carbon.transport.
> http.netty.internal.NettyTransportServiceComponent} - All
> CarbonNettyServerInitializers are available
> [2017-03-09 12:44:44,856]  INFO 
> {org.wso2.msf4j.internal.MicroservicesRegistryImpl}
> - Added microservice: org.wso2.carbon.uuf.httpconnector.msf4j.
> UUFMicroservice@1a3c0a9c
> [2017-03-09 12:44:44,856]  INFO 
> {org.wso2.msf4j.internal.MicroservicesRegistryImpl}
> - Added microservice: org.wso2.carbon.uuf.httpconnector.msf4j.
> UUFMicroservice@1a3c0a9c
> [2017-03-09 12:44:44,857]  WARN {org.wso2.carbon.kernel.
> internal.startupresolver.StartupComponentManager} - You are trying to add
> an available capability org.wso2.msf4j.Microservice from
> bundle(org.wso2.carbon.uuf.httpconnector.msf4j:1.0.0.m13) to an already
> activated startup listener component wso2-microservices-server in
> bundle(msf4j-core:2.1.1). Refer the Startup Order Resolver documentation
> and validated your configuration
> [2017-03-09 12:44:44,857]  INFO {org.wso2.carbon.uuf.
> httpconnector.msf4j.internal.MSF4JHttpConnector} - UUF app
> 'org.wso2.carbon.apimgt.web.store' is available at '/store'.
> [2017-03-09 12:44:44,859]  INFO 
> {org.wso2.msf4j.internal.MicroservicesRegistryImpl}
> - Added microservice: org.wso2.carbon.uuf.httpconnector.msf4j.
> UUFMicroservice@3178a583
> [2017-03-09 12:44:44,859]  INFO 
> {org.wso2.msf4j.internal.MicroservicesRegistryImpl}
> - Added microservice: org.wso2.carbon.uuf.httpconnector.msf4j.
> UUFMicroservice@3178a583
> [2017-03-09 12:44:44,859]  WARN {org.wso2.carbon.kernel.
> internal.startupresolver.StartupComponentManager} - You are trying to add
> an available capability org.wso2.msf4j.Microservice from
> bundle(org.wso2.carbon.uuf.httpconnector.msf4j:1.0.0.m13) to an already
> activated startup listener component wso2-microservices-server in
> bundle(msf4j-core:2.1.1). Refer the Startup Order Resolver documentation
> and validated your configuration
> [2017-03-09 12:44:44,860]  INFO {org.wso2.carbon.uuf.
> httpconnector.msf4j.internal.MSF4JHttpConnector} - UUF app
> 'org.wso2.carbon.apimgt.web.publisher' is available at '/publisher'.
> [2017-03-09 12:44:44,861]  INFO 
> {org.wso2.msf4j.internal.MicroservicesRegistryImpl}
> - Added microservice: org.wso2.carbon.uuf.httpconnector.msf4j.
> UUFMicroservice@2d9caac3
> [2017-03-09 12:44:44,861]  INFO 
> {org.wso2.msf4j.internal.MicroservicesRegistryImpl}
> - Added microservice: org.wso2.carbon.uuf.httpconnector.msf4j.
> UUFMicroservice@2d9caac3
>
> Do we really need to create new micro service for each path? What's the
> reason behind this?
>
> Some of the services below can be combined to one, for example
> org.wso2.carbon.apimgt.rest.api.publisher.ApisApi,
> org.wso2.carbon.apimgt.rest.api.publisher.ApplicationsApi,
> org.wso2.carbon.apimgt.rest.api.publisher.EndpointsApi,
> org.wso2.carbon.apimgt.rest.api.publisher.EnvironmentsApi,
> org.wso2.carbon.apimgt.rest.api.publisher.LabelsApi,
> org.wso2.carbon.apimgt.rest.api.publisher.SubscriptionsApi can be
> combined to one micro service, since they can be functionally categorized
> together as publisher micro service.
>
> org.wso2.carbon.apimgt.rest.api.store.ApisApi,
> org.wso2.carbon.apimgt.rest.api.store.ApplicationsApi,
> org.wso2.carbon.apimgt.rest.api.store.PoliciesApi,
> org.wso2.carbon.apimgt.rest.api.store.SubscriptionsApi,
> org.wso2.carbon.apimgt.rest.api.store.TagsApi can be combined to one
> micro service, since they can be functionally categorized together as store
> micro service.
>
> Also, we need to eliminate micro service on which runs on HTTP and need 

Re: [Architecture] [G-Reg 5] Removing org.wso2.carbon.registry.api from the code

[Afkham Azeez]

On Wed, Nov 6, 2013 at 8:37 AM, Eranda Sooriyabandara wrote:

> Hi Azeez,
>
>
> On Wed, Nov 6, 2013 at 8:28 AM, Afkham Azeez  wrote:
>
>> Rather than removing registry.api, start cleaning it up & use it. In
>> 2010, we introduced registry.api & user-api, with a view to getting all
>> future code to properly use those APIs, and stop using interfaces from
>> registry.core & user.core.
>>
>
> The problem we have here is that we have same interfaces in registry.api.*
> as well as registry.core.* which is quite confusing for a user, where
> registry.api.* has less method descriptions which are in use.
> So you are suggesting that we need to move all the interfaces to
> registry.api.*, yes that can be done but as I mentioned before it will
> affect all the components, stubs features and the effort will be high.
>

Yeah, effort will be high. It has not gotten done over the past 3 years
because the effort was going to be high. Make a choice: keep maintaining &
adding to an ugly API with implementation leaked all over it, or make an
effort to define a well thought out clean API separate from the
implementation, and get all components to depend on the registry
implementation details.


>
> thanks
> Eranda
>
>
>>
>> I am -1 on removing this
>>
>> Azeez
>>
>>
>> On Tue, Nov 5, 2013 at 6:07 PM, Eranda Sooriyabandara wrote:
>>
>>> Hi All,
>>> Interfaces and classes in org.wso2.carbon.registry.api.* are almost all
>>> duplicated [1] in org.wso2.carbon.registry.core.*. It's been very confusing
>>> to have same interface in two place where both of those interfaces used for
>>> the same purpose. Most of the time we used org.wso2.carbon.registry.core.*
>>> for in our code as well as client codes where we only updated
>>> org.wso2.carbon.registry.core.* for the new methods.  I did some
>>> feasibility study of removing org.wso2.carbon.registry.api.* and seems it's
>>> ok for me to remove that if we don't have any specific reason to remove it.
>>>
>>> Or
>>>
>>> We can move the interfaces and abstract classes to
>>> the org.wso2.carbon.registry.api.*. But the work load will be much higher.
>>>
>>> Comments and thoughts are welcome.
>>>
>>> thanks
>>> Eranda
>>>
>>> [1]. Comparison of org.wso2.carbon.registry.api.* to
>>> org.wso2.carbon.registry.core.*
>>>
>>> org.wso2.carbon.registry.core.LogEntry extends
>>> org.wso2.carbon.registry.api.Activity
>>> org.wso2.carbon.registry.api.Activity only used in
>>> org.wso2.carbon.registry.core.LogEntry
>>>
>>> -
>>>
>>> org.wso2.carbon.registry.core.Association extends
>>> org.wso2.carbon.registry.api.Association
>>> org.wso2.carbon.registry.api.Association only used in
>>> org.wso2.carbon.registry.core.Association
>>> This class only has the super construct call
>>>
>>> -
>>>
>>> <>org.wso2.carbon.registry.core.Collection extends
>>> <>org.wso2.carbon.registry.api.Collection
>>> org.wso2.carbon.registry.api.Collection only used in
>>> org.wso2.carbon.registry.core.Collection
>>> All org.wso2.carbon.registry.api.Collection methods are overridden
>>>
>>> -
>>>
>>> org.wso2.carbon.registry.core.Comment implements
>>> org.wso2.carbon.registry.api.Comment
>>> Need to move this to org.wso2.carbon.registry.core and rename the
>>> existing implementation to CommentImpl
>>>
>>> org.wso2.carbon.registry.api.CoreRegistry extends
>>> org.wso2.carbon.registry.core.CoreRegistry
>>> both are same interface
>>> org.wso2.carbon.registry.api.CoreRegistry only used in
>>> org.wso2.carbon.registry.core.CoreRegistry
>>>
>>> -
>>>
>>> org.wso2.carbon.registry.api.GhostResource only appears in
>>> org.wso2.carbon.registry.api
>>>
>>> -
>>> org.wso2.carbon.registry.core.Registry extends
>>> org.wso2.carbon.registry.api.Registry
>>>
>>>  org.wso2.carbon.registry.core.Registry extended methods
>>>
>>>  boolean addAspect(String name, Aspect aspect)
>>>  

Re: [Architecture] [G-Reg 5] Removing org.wso2.carbon.registry.api from the code

[Afkham Azeez]

On Wed, Nov 6, 2013 at 8:45 AM, Eranda Sooriyabandara wrote:

> Hi Azeez,
>
> On Wed, Nov 6, 2013 at 8:33 AM, Afkham Azeez  wrote:
>
>> To add more context, what you have in registry.core is not a proper API.
>> It has implementation details leaked all over the interface. The idea to
>> introduce a clean registry.api started in order to define a proper API.
>> Please spend your time getting that API properly designed & fixed, and used
>> in the rest of the platform, rather than going back to the registry.core
>> interfaces.
>>
>
> I understand the need of registry.api.* and agreed the cleanliness when we
> have interfaces are separated though it is used rarely. So shall we remove
> the main interfaces from registry.core.* and maintain them in
> registry.api.* where users use registry.api.* instead registry.core.* for
> their object references?
>

Yeah, that was the whole idea. Now is a good time to do it since we are
moving to a better architecture & better APIs with C5.


>
> thanks
> Eranda
>
>
>>
>>
>> On Wed, Nov 6, 2013 at 8:28 AM, Afkham Azeez  wrote:
>>
>>> Rather than removing registry.api, start cleaning it up & use it. In
>>> 2010, we introduced registry.api & user-api, with a view to getting all
>>> future code to properly use those APIs, and stop using interfaces from
>>> registry.core & user.core.
>>>
>>> I am -1 on removing this
>>>
>>> Azeez
>>>
>>>
>>> On Tue, Nov 5, 2013 at 6:07 PM, Eranda Sooriyabandara 
>>> wrote:
>>>
>>>> Hi All,
>>>> Interfaces and classes in org.wso2.carbon.registry.api.* are almost all
>>>> duplicated [1] in org.wso2.carbon.registry.core.*. It's been very confusing
>>>> to have same interface in two place where both of those interfaces used for
>>>> the same purpose. Most of the time we used org.wso2.carbon.registry.core.*
>>>> for in our code as well as client codes where we only updated
>>>> org.wso2.carbon.registry.core.* for the new methods.  I did some
>>>> feasibility study of removing org.wso2.carbon.registry.api.* and seems it's
>>>> ok for me to remove that if we don't have any specific reason to remove it.
>>>>
>>>> Or
>>>>
>>>> We can move the interfaces and abstract classes to
>>>> the org.wso2.carbon.registry.api.*. But the work load will be much higher.
>>>>
>>>> Comments and thoughts are welcome.
>>>>
>>>> thanks
>>>> Eranda
>>>>
>>>> [1]. Comparison of org.wso2.carbon.registry.api.* to
>>>> org.wso2.carbon.registry.core.*
>>>>
>>>> org.wso2.carbon.registry.core.LogEntry extends
>>>> org.wso2.carbon.registry.api.Activity
>>>> org.wso2.carbon.registry.api.Activity only used in
>>>> org.wso2.carbon.registry.core.LogEntry
>>>>
>>>>
>>>> -
>>>>
>>>> org.wso2.carbon.registry.core.Association extends
>>>> org.wso2.carbon.registry.api.Association
>>>> org.wso2.carbon.registry.api.Association only used in
>>>> org.wso2.carbon.registry.core.Association
>>>> This class only has the super construct call
>>>>
>>>>
>>>> -
>>>>
>>>> <>org.wso2.carbon.registry.core.Collection extends
>>>> <>org.wso2.carbon.registry.api.Collection
>>>> org.wso2.carbon.registry.api.Collection only used in
>>>> org.wso2.carbon.registry.core.Collection
>>>> All org.wso2.carbon.registry.api.Collection methods are overridden
>>>>
>>>>
>>>> -
>>>>
>>>> org.wso2.carbon.registry.core.Comment implements
>>>> org.wso2.carbon.registry.api.Comment
>>>> Need to move this to org.wso2.carbon.registry.core and rename the
>>>> existing implementation to CommentImpl
>>>>
>>>> org.wso2.carbon.registry.api.CoreRegistry extends
>>>> org.wso2.carbon.registry.core.CoreRegistry
>>>> both are same interface
>>>> org.wso2.carbon.registry.api.CoreRegistry only used in
>>>> org.wso2.carbon.registry.core.CoreRegistry
>>>>
>>>>
>>>> 

Re: [Architecture] [Dev] Distributed Caching

[Afkham Azeez]

Here is a blog post I wrote summarizing the info about the caching impl

http://blog.afkham.org/2013/11/wso2-multi-tenant-cache-jsr-107-jcache.html


On Fri, Nov 22, 2013 at 9:06 AM, Afkham Azeez  wrote:

> The caching implementation we have is an implementation of the JSR-107
> (JCache) spec [1]
>
> If (Axis2) clustering is enabled, the cache works as a distributed cache.
> It is simply using a Hazelcast distributed map [2] per cache. If clustering
> is not enabled, then the same caching implementation works as an a local
> cache. There is no code change required in the code that uses JCache APIs
> to switch from local cache mode to distributed cache mode. In addition, in
> distributed cache mode, in order to improve performance, we have an L1
> cache, which is simply implemented using HashMaps, and the L2 cache is
> implemented using Hazelcast distributed maps. So, we first check the L1
> cache, and if there is a cache miss, we go to the L2 cache. If the value is
> located in the L2 cache, then we also store it in the L1 cache. In
> distributed mode, If a cache entry is removed or invalidated, then
> Hazelcast listeners we have registered get triggered on each & every
> Hazelcast cluster member. That will result in the values in the L1 cache &
> L2 cache being removed.
>
>
> 1.
> https://docs.google.com/document/d/1YZ-lrH6nW871Vd9Z34Og_EqbX_kxxJi55UrSn4yL2Ak/edit
> 2. http://www.hazelcast.com/docs/3.0/manual/multi_html/ch02.html#Map
>
>
>  On Fri, Nov 22, 2013 at 7:52 AM, Srinath Perera  wrote:
>
>>  Pls ask Azeez, architecure@ should have some info
>>
>>
>> On Thu, Nov 21, 2013 at 3:54 PM, Thilini Ishaka  wrote:
>>
>>> Hi,
>>>
>>> Could you please point me to the architecture diagram (if available),
>>> and some notes related to Distributed Caching impl based on Hazelcast.
>>>
>>> Requesting this, in addition to the information in "[Architecture]
>>> Caching implementation performance improvement" mail thread.
>>>
>>> Thanks
>>> Thilini
>>>
>>> --
>>> Thilini Ishaka
>>> Senior Software Engineer
>>> Phone: +94 11 214 5345
>>> WSO2 Inc. http://wso2.com
>>>
>>> bolg: thiliniishaka.blogspot.com
>>> linkedin: http://lk.linkedin.com/in/thiliniishaka
>>> twitter: https://twitter.com/#!/ThiliniIsh
>>>
>>
>>
>>
>> --
>> 
>> Srinath Perera, Ph.D.
>>   Director, Research, WSO2 Inc.
>>   Visiting Faculty, University of Moratuwa
>>   Member, Apache Software Foundation
>>   Research Scientist, Lanka Software Foundation
>>   Blog: http://srinathsview.blogspot.com/
>>   Photos: http://www.flickr.com/photos/hemapani/
>>Phone: 0772360902
>>
>> ___
>> Dev mailing list
>> d...@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> *Afkham Azeez*
> Director of Architecture; WSO2, Inc.; http://wso2.com
> Member; Apache Software Foundation; http://www.apache.org/
> * <http://www.apache.org/>*
> *email: **az...@wso2.com* 
> * cell: +94 77 3320919 <%2B94%2077%203320919> blog: *
> *http://blog.afkham.org* <http://blog.afkham.org>
> *twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
> * linked-in: **http://lk.linkedin.com/in/afkhamazeez
> <http://lk.linkedin.com/in/afkhamazeez>*
>
> *Lean . Enterprise . Middleware*
>



-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919 blog: **http://blog.afkham.org*<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
* linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Registry Exception for C5 work

[Afkham Azeez]

We just had a chat. For most platform concepts, we need to identify an SPI
& API, and separate them out. For example, we need to have Clustering SPI
for clustering implementers, and clustering API for clustering users. SPI
Implementers will write pluggable implementations. The same goes for
Deployment, Repository & User Management.

Azeez


On Tue, Nov 26, 2013 at 9:49 AM, Srinath Perera  wrote:

> Lets do this next week, and lets get Azeez as well.
>
>
> On Mon, Nov 25, 2013 at 5:03 PM, Shazni Nazeer  wrote:
>
>> Hi Srinath,
>>
>> This is regarding the Registry Exceptions model part of the C5 work. We
>> have come up with a model and would like to do an architectural review on
>> that with you. What would be the best time for you to schedule an
>> architectural review for this?
>>
>> regards,
>>
>> Shazni Nazeer
>>
>> Senior Software Engineer
>>
>> Mob : +94 715 440 607
>> LinkedIn : http://lk.linkedin.com/in/shazninazeer
>> Blog : http://shazninazeer.blogspot.com
>>
>
>
>
> --
> 
> Srinath Perera, Ph.D.
>   Director, Research, WSO2 Inc.
>   Visiting Faculty, University of Moratuwa
>   Member, Apache Software Foundation
>   Research Scientist, Lanka Software Foundation
>   Blog: http://srinathsview.blogspot.com/
>   Photos: http://www.flickr.com/photos/hemapani/
>Phone: 0772360902
>
> _______
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919 blog: **http://blog.afkham.org*<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
* linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5] Logging framework

[Afkham Azeez]

I would suggest going with PAX logging,

Azeez


On Thu, Nov 28, 2013 at 12:37 PM, Kishanthan Thangarajah <
kishant...@wso2.com> wrote:

> I'm bringing up this thread to discuss on the logging backend and logging
> framework in C5.
>
> Our current logging framework uses log4j as the logging backend and
> support a set of logging APIs (commons-logging, slf4j, java-logging, log4j
> logger). We currently don't support OSGI LogService. But we need to decide
> on whether do we need to support this as there were some decision made
> earlier not to support?
>
> This framework is serving well so far, but if we have to support other
> logging APIs then we will have to write them.
>
> *Alternatives*
> 1. Log4j2 [1] (logging backend only)
> The next generation of log4j. It is still at the beta stage in release.
> This looks promising as the numbers of this is way ahead of its predecessor
> [2].
>
> 2. Pax logging [3] (complete framework)
> This framework uses a similar concept as ours. It uses log4j as the
> backend and support a whole set of logging APIs such as commons-logging
> API, log4J-logger API, jdk-logging, avalon-logger API, knopflerfish-log and
> tomcat-juli. It also has support for OSGI LogService API.
>
> So far we found that Pax logging has the support for all required logging
> APIs including the support for OSGI LogService.
>
> Other projects mostly have written their own way to handle different
> logging APIs like ours.
>
> Thoughts and ideas are welcome !
>
> Thanks,
> Kishanthan.
> [1] http://logging.apache.org/log4j/2.x/
>  [2]
> http://www.javacodegeeks.com/2013/07/log4j-2-performance-close-to-insane.html
> [3] https://ops4j1.jira.com/wiki/display/paxlogging/Pax+Logging
>
> --
> *Kishanthan Thangarajah*
> Senior Software Engineer,
> Platform Technologies Team,
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile - +94773426635
> Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>*
> Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>*
>



-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919 blog: **http://blog.afkham.org*<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
* linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5] WSO2 Carbon Kernel 5.0.0 - M1 Release

[Afkham Azeez]

On Fri, Dec 13, 2013 at 10:52 PM, Sanjiva Weerawarana wrote:

> Congratulations C5 team!
>

Nice work! Keep the momentum going.

>
> Hmmm ... "legacy technologies like Axis2" .. ouch.
>

As sad as it sounds, this is the reality. However, we have got this far
because of the things we learnt while creating & using Axis2.
Unfortunately, the true potential of the Axis2 server framework was never
realized by people outside WSO2, and the users & community simply saw it as
just another Web services framework.


>
> Sanjiva.
> p.s.: s/GitHup/GitHub/.
>
>
> On Thu, Dec 12, 2013 at 1:10 PM, Sameera Jayasoma wrote:
>
>> Hi All,
>>
>> We are happy to inform you that the release of the first milestone of
>> Carbon kernel 5.0.0. You can download the release distribution from [1].
>>
>> *What is Carbon Kernel 5?*
>> Carbon kernel 5 is the next generation of WSO2 Carbon
>> kernel, re-architected from the ground up with the latest technologies to
>> overcome the existing architectural limitations as well as to get rid of
>> the dependencies to the legacy technologies like Apache Axis2.
>>
>> This milestone release includes the bare minimum features for an OSGi
>> runtime.
>>
>> *New Features*
>>
>>- Equinox Kepler based light-weight OSGi runtime.
>>- New Carbon launcher implementation
>>- Centralized logging back-end (based on Log4j) which supports
>>multiple logging APIs.
>>
>> *How to contribute?*
>> C5 code is now available in GitHup[2]. You can clone this repository and
>> do a maven build from the root. If you have any suggestions or interested
>> in C5 discussions, please do so via *d...@wso2.org * or 
>> *architecture@wso2.org
>> * mailing lists.
>>
>> Please report bugs, if any here[3]
>>
>> *Known Issues*
>> https://wso2.org/jira/browse/CARBON-14585?filter=11693
>>
>> Thanks,
>> *C5 Team.*
>>
>> [1]
>> http://svn.wso2.org/repos/wso2/people/sameera/work/carbon-5.0.0/milestone-1/wso2carbon-kernel-5.0.0-SNAPSHOT.zip
>> [2] https://github.com/wso2/carbon-kernel
>> [3] https://wso2.org/jira/browse/CARBON
>>
>> --
>> Sameera Jayasoma,
>> Architect,
>>
>> WSO2, Inc. (http://wso2.com)
>> email: same...@wso2.com
>> blog: http://sameera.adahas.org
>> twitter: https://twitter.com/sameerajayasoma
>> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections
>> Mobile: 0094776364456
>>
>> Lean . Enterprise . Middleware
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Sanjiva Weerawarana, Ph.D.
> Founder, Chairman & CEO; WSO2, Inc.;  http://wso2.com/
> email: sanj...@wso2.com; office: +1 650 745 4499 x5700; cell: +94 77 787
> 6880 | +1 650 265 8311
> blog: http://sanjiva.weerawarana.org/
>
> Lean . Enterprise . Middleware
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919 blog: **http://blog.afkham.org*<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
* linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5] Should we use "api" in the API package name ?

[Afkham Azeez]

We need a clear mechanism to indicate what is the API & what is the
implementation. We also need to clearly indicate what is the SPI, where
relevant. Not clearly separating these out has resulted in implementation
details leaking into APIs.


On Sat, Dec 14, 2013 at 6:58 PM, Sameera Jayasoma  wrote:

> +1 for not using the the word "api" in the package name.
>
> In addition I've seen many place where people have used the word
> "internal" to include the implementation classes of an API.
>
> e.g.
>
> org.wso2.carbon.registry.core --> API
> org.wso2.carbon.registry.core.internal --> Implementation.
>
> If we follow a similar approach then we can easily decide which packages
> to share and which packages to hide from an OSGi bundle.
>
> Thanks,
> Sameera.
>
>
> On Sat, Dec 14, 2013 at 6:00 PM, Prabath Siriwardena wrote:
>
>> Should we use "api" in the API package name ?
>>
>> I think we should not..
>>
>> Currently we have org.wso2.carbon.user.api, org.wso2.carbon.regostry.api
>> and possibly many more..
>>
>> I think should avoid putting API in the package name - and it should be
>> quite obvious..
>>
>> For example, in Java - in JDBC API [1] - there in no API package name..
>>
>> Also - the Java Collections API [2] - and JMS API [3]
>>
>> It has been an industry best practice to not to use the word "api" in
>> package name..
>>
>> I think we should follow that too ?
>>
>> [1]: http://docs.oracle.com/javase/7/docs/technotes/guides/jdbc/
>> [2]: http://docs.oracle.com/javase/7/docs/api/java/util/Collections.html
>> [3]: http://docs.oracle.com/javaee/6/api/javax/jms/package-summary.html
>>
>> Thanks & Regards,
>> Prabath
>>
>> Twitter : @prabath
>> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena
>>
>> Mobile : +94 71 809 6732
>>
>> http://blog.facilelogin.com
>> http://blog.api-security.org
>>
>
>
>
> --
> Sameera Jayasoma,
> Architect,
>
> WSO2, Inc. (http://wso2.com)
> email: same...@wso2.com
> blog: http://sameera.adahas.org
> twitter: https://twitter.com/sameerajayasoma
> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections
> Mobile: 0094776364456
>
> Lean . Enterprise . Middleware
>



-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919 blog: **http://blog.afkham.org*<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
* linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Persisting runtime throttle data

[Afkham Azeez]

p need to be persisted?
>  As a thought, we should persist the CallerContext every 5-10 seconds (IMO
> this should be a medium prio thread).  Can we make this value configurable?
>
> 5. Any chance of losing most recent runtime throttle info as we are not
> persisting on each request?
> Yes there is.  But this is a trade-off between performance and the
> requirement to persist throttle conters.  Making the throttle persistence
> interval configurable is a measure to control this.
>
>
> 6. What needs to be persisted?
> The following at a minimum
>
> ID : string /* The Id of caller */
> nextAccessTime : long /* next access time - the end of prohibition */
> firstAccessTime : long /* when caller came across the on first time */
> nextTimeWindow : long /* beginning of next unit time period */
> count : int /* number of requests */
>
> If we opt to use Option B for handling throttle persistence in a cluster
> we will have to persist the nodeID in addition to these.
>
>
>
> [1]
> https://docs.google.com/a/wso2.com/document/d/1AQOH-23jM37vjtzqoWg7vokUTsyaWh3eJLLoYQXYlf0
>
>
> Thoughts?
>
> Regards,
> Manoj
> --
> Manoj Fernando
> Director - Solutions Architecture
>
> Contact:
> LK -  +94 112 145345
> Mob: +94 773 759340
> www.wso2.com
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919 blog: **http://blog.afkham.org*<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
* linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Persisting runtime throttle data

[Afkham Azeez]

On Wed, Dec 18, 2013 at 9:39 AM, Manoj Fernando  wrote:

> Hi Azeez,
>
> hmmm true... I too came across quite a few 'canAccess' calls that I felt
> could be simplified.  However, this is certainly a bigger change than just
> introing persistence.  So how should we proceed from this point onwards?  A
> complete rewrite of the throttle core means that we will have to have
> another broader look of the whole module.  IMO, we can retain the ipbase,
> rolebase, and domainbase APIs, yet will have to re-write the Controller
> logic (i.e. ConcurrentAccessThrottler, and RoleBasedAccessRateThrottler +
> helpers).
>
> Shall we start a new thread for a re-write then?
>

Yeah, +1. The original throttling code was written in 2006 & has not been
used much in clustered deployments until recently. It would be best to
reimplement it with all the requirements in mind.


> Regards.
> Manoj
>
>
> On Tue, Dec 17, 2013 at 9:28 PM, Afkham Azeez  wrote:
>
>> Hi Manoj,
>> While working on a critical state replication issue in throttling core,
>> we figured that the code can be better written. Piling on changes on to
>> that code will only make it worse, and even now the code looks
>> unmaintainable. I would prefer redesigning & rewriting throttling core from
>> scratch taking into consideration persistence & state replication.
>>
>> Azeez
>>
>>
>> On Mon, Dec 16, 2013 at 9:15 AM, Manoj Fernando  wrote:
>>
>>> All,
>>>
>>> We have a requirement for $subject.  Like to hear your thoughts first on
>>> the following plan, and setup a review session accordingly.
>>>
>>> Google doc @ [1] with permissions to comment.
>>>
>>> *Background*
>>> Throttling is a core carbon component that provides API throttling
>>> across the platform.  The current implementation supports Role and
>>> Concurrency based throttling which is used by products for more business
>>> specific use cases.  For example, the APIM uses the throttling framework to
>>> provide throttling support at 3 levels.
>>>
>>>- Application Level - Policy is applied to the whole Application
>>>(overrides any policy violations at the other 2 levels)
>>>- API Level - Policy is applied at each API level (overrides any
>>>policy violations at API Resource level)
>>>- API Resource Level - Policy is applied at each API resource (i.e.
>>>GET, POST, etc.)
>>>
>>>
>>> *Problem*
>>> At present, the core carbon framework does not persist the runtime
>>> throttling data.  For example, a role based APIM throttling policy may
>>> specify that 50 requests be handled per minute, and if the APIM gateway
>>> crashes at the 50th second having served 40 requests, a restart will cause
>>> in APIM providing the full quota once the node is restarted.
>>>
>>>
>>> *Current Design*
>>>
>>>
>>>
>>>
>>>- ThrottleContext is initialized by APIThrottleHandler (in the case
>>>of API Manager) at the time of the first authenticated request hitting 
>>> the
>>>gateway.
>>>- The APIThrottleHandler uses the ThrottleFactory (carbon core
>>>class) to instantiate a ThrottleContext object.
>>>- ThrottleContext keeps a map of CallerContext objects of which the
>>>runtime throttle counters are kept, corresponding to each policy 
>>> definition
>>>(e.g.  A throttle scenario mapping the tier policy ‘Gold’ will initiate a
>>>CallerContext at the first instance of the policy is matched.)
>>>- For every new CallerContext instance, the ThrottleContext will
>>>push that CallerContext instance to a Map.
>>>- ThrottleContext exposes the ‘addCallerContext’ and
>>>‘removeCallerContext’ methods to add and to cleanup the expired context
>>>objects.
>>>- CallerContext keeps the caller count, and access times related to
>>>the Caller.
>>>- In the case of API Manager, each caller instance (based on the
>>>tier configuration), access the ThrottleContext using the
>>>doRoleBasedAccessThrottling and doThrottleByConcurrency methods.
>>>
>>>
>>> *Implementing Persistence*
>>>
>>>
>>>- ThrottleContext is independently initialized by any component
>>>using the throttling framework.
>>>- What needs to  be persisted is the CallerContext map together with
>>>the initiator attributes (i.e. TrottleID)
>>>  

Re: [Architecture] [C5] Maintaining orbit as an external project

[Afkham Azeez]

On Fri, Jan 3, 2014 at 3:16 PM, Samisa Abeysinghe  wrote:

> Why do we need SNAPSHOT for orbits at all? It is just a wrapper of a
> released lib. So just create the new version and deploy into m2 - Done!
>
>
+1. This is what I suggested some time back too.


>  Thanks,
> Samisa...
>
>
> Samisa Abeysinghe
>
> Vice President Developer Evangelism
>
> WSO2 Inc.
> http://wso2.com
>
>
>
> On Fri, Jan 3, 2014 at 2:43 PM, Kishanthan Thangarajah <
> kishant...@wso2.com> wrote:
>
>> Our current approach of having third party dependencies as OSGi bundles
>> is to make them into an orbit project. The release of them happen with the
>> kernel or platform release.
>>
>> Because of this, currently when building carbon from source, we first
>> have to build orbit. But this is not needed if we maintain orbit as an
>> external project (may be in git-hub) and use one of the following.
>>
>> 1. Use SNAPSHOT repo approach. The developer who creates a new orbit
>> project will have to deploy the snapshot version of it to the repo. The
>> official release of those will happen on its own way. It can align either
>> with a kernel release or platform release (major or patch releases).
>>
>> 2. Releasing the newly created orbit project immediately after creating
>> it. This is possible because we don't normally do any changes to it (pom)
>> afterwards. This also has to be done by the developer (after all the
>> testing). The downside of this is we may end up with multiple versions for
>> a projects. But this will be minimal.
>>
>> In both cases above, the components requiring those orbit dependencies
>> will have to update to those released/snapshot versions.
>>
>> The orbit projects for forked dependencies will follow the same approach
>> as earlier.
>>
>> Suggestions and thoughts are welcome.
>>
>> Thanks,
>> Kishanthan.
>>
>> --
>> *Kishanthan Thangarajah*
>> Senior Software Engineer,
>> Platform Technologies Team,
>> WSO2, Inc.
>> lean.enterprise.middleware
>>
>> Mobile - +94773426635
>> Blog - *http://kishanthan.wordpress.com
>> <http://kishanthan.wordpress.com>*
>> Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>*
>>
>> _______
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919 blog: **http://blog.afkham.org*<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
* linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Using JPA for Data Access in C5

[Afkham Azeez]

When we wrote Tungsten, we were using Hibernate instead of direct SQL.
However, when we started implementing Registry, there were long discussions
on whether to use an ORM or direct JDBC, and we made the decision to use
direct JDBC since we didn't want an additional layer & there were arguments
about performance, even though even at that time, Hibernate had lots of
performance optimizations like a write through cache.


On Fri, Jan 3, 2014 at 2:11 PM, Anjana Fernando  wrote:

> Hi,
>
> I saw that, we are cleaning up the registry/user-manager APIs for C5 and
> re-writing some stuff. So I was wondering, if we can use JPA instead of
> writing our own SQL scripts and writing the DAOs and maintaing them in the
> platform. Having our own SQL scripts and the SQL in the code can be a bit
> messy and it can get complicated when supporting new databases and so on.
>
> So, by simply using a JPA provider, we offload all these complexities of
> generating SQL for different types of database and all to the JPA
> implementation. And also, with this, we can also possibly support non-RDBMS
> data stores as well, like MongoDB, which is supported by EclipseLink and
> DataNucleus.
>
> I guess, the only concern with JPA would be any possible performance
> implications, but I guess now a days JPA implementations must be pretty
> optimised, and must be generating good SQL or maybe even better than our
> custom ones, where as, they can generate custom SQL per database type. And
> in the case of data stores such as MongoDB, we may want to check how
> transactions and all would work. So if possible, we can do a PoC and see
> how it can work out.
>
> Cheers,
> Anjana.
> --
> *Anjana Fernando*
> Technical Lead
> WSO2 Inc. | http://wso2.com
> lean . enterprise . middleware
>



-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919 blog: **http://blog.afkham.org*<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
* linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5] Maintaining orbit as an external project

[Afkham Azeez]

Why do we have to patch orbits (except Axis2 & Synapse)? IMO, changes to
orbits is not frequent, and if you need to change it, you have to reversion
it.


On Fri, Jan 3, 2014 at 3:59 PM, Supun Malinga  wrote:

> Hi,
>
> Currently the process to release new orbit version is not good IMO due to
> kernel patch process. We have to release the orbits as a kernel patch as
> well AFAIK. So we should have a better approach there. Do we get a solution
> for that with this suggestion?.
>
> thanks,
>
>
> On Fri, Jan 3, 2014 at 3:21 PM, Afkham Azeez  wrote:
>
>>
>>
>>
>> On Fri, Jan 3, 2014 at 3:16 PM, Samisa Abeysinghe wrote:
>>
>>> Why do we need SNAPSHOT for orbits at all? It is just a wrapper of a
>>> released lib. So just create the new version and deploy into m2 - Done!
>>>
>>
>>>
>> +1. This is what I suggested some time back too.
>>
>>
>>>  Thanks,
>>> Samisa...
>>>
>>>
>>> Samisa Abeysinghe
>>>
>>> Vice President Developer Evangelism
>>>
>>> WSO2 Inc.
>>> http://wso2.com
>>>
>>>
>>>
>>> On Fri, Jan 3, 2014 at 2:43 PM, Kishanthan Thangarajah <
>>> kishant...@wso2.com> wrote:
>>>
>>>> Our current approach of having third party dependencies as OSGi bundles
>>>> is to make them into an orbit project. The release of them happen with the
>>>> kernel or platform release.
>>>>
>>>> Because of this, currently when building carbon from source, we first
>>>> have to build orbit. But this is not needed if we maintain orbit as an
>>>> external project (may be in git-hub) and use one of the following.
>>>>
>>>> 1. Use SNAPSHOT repo approach. The developer who creates a new orbit
>>>> project will have to deploy the snapshot version of it to the repo. The
>>>> official release of those will happen on its own way. It can align either
>>>> with a kernel release or platform release (major or patch releases).
>>>>
>>>> 2. Releasing the newly created orbit project immediately after creating
>>>> it. This is possible because we don't normally do any changes to it (pom)
>>>> afterwards. This also has to be done by the developer (after all the
>>>> testing). The downside of this is we may end up with multiple versions for
>>>> a projects. But this will be minimal.
>>>>
>>>> In both cases above, the components requiring those orbit dependencies
>>>> will have to update to those released/snapshot versions.
>>>>
>>>> The orbit projects for forked dependencies will follow the same
>>>> approach as earlier.
>>>>
>>>> Suggestions and thoughts are welcome.
>>>>
>>>> Thanks,
>>>> Kishanthan.
>>>>
>>>> --
>>>> *Kishanthan Thangarajah*
>>>> Senior Software Engineer,
>>>> Platform Technologies Team,
>>>> WSO2, Inc.
>>>> lean.enterprise.middleware
>>>>
>>>> Mobile - +94773426635
>>>> Blog - *http://kishanthan.wordpress.com
>>>> <http://kishanthan.wordpress.com>*
>>>> Twitter - *http://twitter.com/kishanthan
>>>> <http://twitter.com/kishanthan>*
>>>>
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> *Afkham Azeez*
>> Director of Architecture; WSO2, Inc.; http://wso2.com
>> Member; Apache Software Foundation; http://www.apache.org/
>> * <http://www.apache.org/>*
>> *email: **az...@wso2.com* 
>> * cell: +94 77 3320919 <%2B94%2077%203320919> blog: *
>> *http://blog.afkham.org* <http://blog.afkham.org>
>> *twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
>> * linked-in: **http://lk.linkedin.com/in/afkhamazeez
>> <http://lk.linkedin.com/in/afkhamazeez>*
>>
>> *Lean . Enterprise . Middleware*
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Supun Malinga,
>
> Senior Software Engineer,
> WSO2 Inc.
> http://wso2.com
> email: sup...@wso2.com 
> mobile: +94 (0)71 56 91 321
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919 blog: **http://blog.afkham.org*<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
* linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5] Maintaining orbit as an external project

[Afkham Azeez]

On Fri, Jan 3, 2014 at 6:57 PM, Sameera Jayasoma  wrote:

> But there is a risk of releasing the orbit bundle just after creating.
> Those orbit bundles may get changed multiple times during the bug fixing
> phase.  So we will end up releasing multiple minor versions. Just a thought.
>

How many times has that happened in the past? The orbit the OSGifies an
already released jar. What is so complex about that & why would we
repeatedly be making mistakes in such a simple task?


>
> Anyway I am +1 for releasing orbits immediately.
>
>
> On Fri, Jan 3, 2014 at 3:21 PM, Afkham Azeez  wrote:
>
>>
>>
>>
>> On Fri, Jan 3, 2014 at 3:16 PM, Samisa Abeysinghe wrote:
>>
>>> Why do we need SNAPSHOT for orbits at all? It is just a wrapper of a
>>> released lib. So just create the new version and deploy into m2 - Done!
>>>
>>>
>> +1. This is what I suggested some time back too.
>>
>>
>>>  Thanks,
>>> Samisa...
>>>
>>>
>>> Samisa Abeysinghe
>>>
>>> Vice President Developer Evangelism
>>>
>>> WSO2 Inc.
>>> http://wso2.com
>>>
>>>
>>>
>>> On Fri, Jan 3, 2014 at 2:43 PM, Kishanthan Thangarajah <
>>> kishant...@wso2.com> wrote:
>>>
>>>> Our current approach of having third party dependencies as OSGi bundles
>>>> is to make them into an orbit project. The release of them happen with the
>>>> kernel or platform release.
>>>>
>>>> Because of this, currently when building carbon from source, we first
>>>> have to build orbit. But this is not needed if we maintain orbit as an
>>>> external project (may be in git-hub) and use one of the following.
>>>>
>>>> 1. Use SNAPSHOT repo approach. The developer who creates a new orbit
>>>> project will have to deploy the snapshot version of it to the repo. The
>>>> official release of those will happen on its own way. It can align either
>>>> with a kernel release or platform release (major or patch releases).
>>>>
>>>> 2. Releasing the newly created orbit project immediately after creating
>>>> it. This is possible because we don't normally do any changes to it (pom)
>>>> afterwards. This also has to be done by the developer (after all the
>>>> testing). The downside of this is we may end up with multiple versions for
>>>> a projects. But this will be minimal.
>>>>
>>>> In both cases above, the components requiring those orbit dependencies
>>>> will have to update to those released/snapshot versions.
>>>>
>>>> The orbit projects for forked dependencies will follow the same
>>>> approach as earlier.
>>>>
>>>> Suggestions and thoughts are welcome.
>>>>
>>>> Thanks,
>>>> Kishanthan.
>>>>
>>>> --
>>>> *Kishanthan Thangarajah*
>>>> Senior Software Engineer,
>>>> Platform Technologies Team,
>>>> WSO2, Inc.
>>>> lean.enterprise.middleware
>>>>
>>>> Mobile - +94773426635
>>>> Blog - *http://kishanthan.wordpress.com
>>>> <http://kishanthan.wordpress.com>*
>>>> Twitter - *http://twitter.com/kishanthan
>>>> <http://twitter.com/kishanthan>*
>>>>
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> *Afkham Azeez*
>> Director of Architecture; WSO2, Inc.; http://wso2.com
>> Member; Apache Software Foundation; http://www.apache.org/
>> * <http://www.apache.org/>*
>> *email: **az...@wso2.com* 
>> * cell: +94 77 3320919 <%2B94%2077%203320919> blog: *
>> *http://blog.afkham.org* <http://blog.afkham.org>
>> *twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
>> * linked-in: **http://lk.linkedin.com/in/afkhamazeez
>> <http://lk.linkedin.com/in/afkhamazeez>*
>>
>> *Lean . Enterprise . Middleware*
>>
>> ___
>>

Re: [Architecture] Equinox Luna will redesign the equinox framework and core compare to equinox kepler

[Afkham Azeez]

For the moment, let's keep the C5 momentum going. As discussed in the
offsite meeting, we should focus more on getting the full benefit of proper
dynamic OSGi behavior. We should be able to upgrade bundles to newer
version. We should be able to patch the servers, without restarting them.
The features in Luna are nice to have, but let's not lose focus on what
we've already planned.

Azeez


On Sun, Jan 12, 2014 at 7:19 PM, Shameera Rathnayaka wrote:

> Hi Sameera,
>
> +1 for use Equniox Luna as C5 OSGi framework, Yes considering the C5
> release schedule with Luna, we can't hold our works that far.
>
> BTW I will play little bit with Equinox kepler framework hooks
> implementation to get an idea on how could we achive osgi level multi
> tenancy in C5. That will be a good background knowledge when we migrate to
> Equinox Luna.
>
> Thanks,
> Shameera.
>
> On Sun, Jan 12, 2014 at 6:30 PM, Sameera Jayasoma wrote:
>
>> Hi Shameera,
>>
>> Looks like Equinox Luna is a complete revamp of the existing Equinox code
>> base to fix the core issues in Equinox. This is just like implementing C5
>> to overcome the architectural issues in C4.
>>
>> We should consider Luna as the OSGi framework implementation for C5. But
>> my only concern is the Luna release schedule[1]. It does not align with the
>> C5 plan as of now. The scheduled release date of Luna is June 25th, 2014.
>>
>> I guess we should continue with Kepler for the moment. As Tom explained
>> there will not be any impact to the APIs except for the hooks which we are
>> yet to use.  Once Luna is in a releasable state we should go for it.
>>
>> Thanks,
>> Sameera.
>>
>> [1] https://projects.eclipse.org/projects/rt.equinox/releases/4.4.0
>>
>>
>> On Sun, Jan 12, 2014 at 11:49 AM, Shameera Rathnayaka 
>> wrote:
>>
>>> Hi devs,
>>>
>>> One of our major expectation with new Carbon 5 release is, use new
>>> technologies which will last for another 10 years. Hence we are using newly
>>> released version of equinox which is equinox kepler. But according to
>>> equinox team, with next major release which is equinox Luna , they are
>>> going to redesign the framework and core[1].
>>>
>>> As we are planing to provide OSGi level multi-tenancy, which can be
>>> implement with framework hooks going to be completely changed with
>>> suggested framework redesign process. Not only the framework hooks there
>>> are few more areas will be change with Luna release. There are few
>>> limitations plus drawbacks in existing framework implementation. Tom Watson
>>> have explained the background reason for this new redesigning
>>> requirement[2].
>>>
>>> If we go with kepler and migrate to Luna once it released , we need to
>>> put the exact same effort again to adopt to new framework changes.
>>>
>>> According to me once the Equnox Luna released kepler will be outdated
>>> equinox implantations. I would like to know your thoughts on what is the
>>> best way to deal with this new equinox famework redesign.
>>>
>>> [1] http://wiki.eclipse.org/Equinox/Luna_Framework
>>> [2]
>>> http://www.eclipsecon.org/2013/sites/eclipsecon.org.2013/files/EclipseCon%202013%20-%20Equinox_0.pdf
>>>
>>>
>>>
>>>
>>> * Thanks, Shameera.Software Engineer - WSO2 Inc.*
>>> *email: shameera AT wso2.com  , shameera AT
>>> apache.org *
>>> *phone:  +9471 922 1454 <%2B9471%20922%201454>*
>>>
>>> *Linked in : *http://lk.linkedin.com/pub/shameera-rathnayaka/1a/661/561
>>> *Twitter : *https://twitter.com/Shameera_R
>>>
>>
>>
>>
>> --
>> Sameera Jayasoma,
>> Architect,
>>
>> WSO2, Inc. (http://wso2.com)
>> email: same...@wso2.com
>> blog: http://sameera.adahas.org
>> twitter: https://twitter.com/sameerajayasoma
>> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections
>> Mobile: 0094776364456
>>
>> Lean . Enterprise . Middleware
>>
>
>


-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919 blog: **http://blog.afkham.org*<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
* linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5] Clustering API

[Afkham Azeez]

Anjana & Suho,
Please review this & let us know whether these APIs address your
requirements.

Azeez


On Wed, Jan 15, 2014 at 1:40 PM, Kishanthan Thangarajah  wrote:

> This thread is to discuss about $subject.
>
> Our current clustering API's contains stuffs that are mixture of both user
> level and developer level API. We will have to separate out these with the
> clear definition.
>
> For clustering API (user level), we will have the following methods. We
> can discuss clustering SPI's on a separate thread.
>
> *void sendMessage(ClusterMessage clusterMessage);*
>
> *void sendMessage(ClusterMessage clusterMessage, List
> members);*
>
> *List getMembers();*
>
> *void addMembershipListener(MembershipListener membershipListener);*
>
> *void removeMembershipListener(MembershipListener membershipListener);*
>
> In here we also thought of having MembershipListener (A listener which
> gets notified when changes occur in Membership) related API at user level.
> This will be useful when user wants to get some event notification when the
> current membership changes. Adding a new MembershipListener will follow the
> white board pattern.
>
> The API for MembershipListener
>
> *void memberAdded(MembershipEvent event);*
>
> *void memberRemoved(MembershipEvent event);*
>
> MembershipEvent will be of two types (member added or removed).
>
> Thoughts?
>
> Thanks,
> Kishanthan.
> --
> *Kishanthan Thangarajah*
> Senior Software Engineer,
> Platform Technologies Team,
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile - +94773426635
> Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>*
> Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>*
>



-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919 blog: **http://blog.afkham.org*<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
* linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Using a single port in clustering instead of multiple ports

[Afkham Azeez]

On Wed, Jan 15, 2014 at 11:58 PM, Manuranga Perera  wrote:

> Current implementation (correct me if I am wrong):
> In Hazalcast clustering implementation, different ports are used for each
> cluster. This is to stop clutter a single port which was not a scalable
> solution.
>

No. Same port different domains work fine.


>
> My question:
> Can we get the same (or almost same) benefit by using the same port, but
> putting each cluster in a different Hazalcast group?
>
> Reason:
> In AWS like deployment, opening up ports and managing them with each
> server start-up takes a significant effort on the infrastructure side. So
> if this can be avoided without much adverse effect it would be worth
> considering.
>
> --
> With regards,
> *Manu*ranga Perera.
>
> phone : 071 7 70 20 50
> mail : m...@wso2.com
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919 blog: **http://blog.afkham.org*<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
* linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5] Clustering API

[Afkham Azeez]

On Thu, Jan 16, 2014 at 4:55 PM, Kishanthan Thangarajah  wrote:

> Adding more.
>
> Since we will follow the whiteboard pattern for adding new
> MembershipListener's, we don't need to have the methods (
> *addMembershipListener, **addMembershipListener*) explicitly at API
> level. Users will implement their MembershipListener's and register it as
> an OSGi service. The clustering component will discover these and add it
> the cluster impl.
>
>
+1



>
> On Wed, Jan 15, 2014 at 3:03 PM, Afkham Azeez  wrote:
>
>> Anjana & Suho,
>> Please review this & let us know whether these APIs address your
>> requirements.
>>
>> Azeez
>>
>>
>> On Wed, Jan 15, 2014 at 1:40 PM, Kishanthan Thangarajah <
>> kishant...@wso2.com> wrote:
>>
>>> This thread is to discuss about $subject.
>>>
>>> Our current clustering API's contains stuffs that are mixture of both
>>> user level and developer level API. We will have to separate out these with
>>> the clear definition.
>>>
>>> For clustering API (user level), we will have the following methods. We
>>> can discuss clustering SPI's on a separate thread.
>>>
>>> *void sendMessage(ClusterMessage clusterMessage);*
>>>
>>> *void sendMessage(ClusterMessage clusterMessage, List
>>> members);*
>>>
>>> *List getMembers();*
>>>
>>> *void addMembershipListener(MembershipListener membershipListener);*
>>>
>>> *void removeMembershipListener(MembershipListener
>>> membershipListener);*
>>>
>>> In here we also thought of having MembershipListener (A listener which
>>> gets notified when changes occur in Membership) related API at user level.
>>> This will be useful when user wants to get some event notification when the
>>> current membership changes. Adding a new MembershipListener will follow the
>>> white board pattern.
>>>
>>> The API for MembershipListener
>>>
>>> *void memberAdded(MembershipEvent event);*
>>>
>>> *void memberRemoved(MembershipEvent event);*
>>>
>>> MembershipEvent will be of two types (member added or removed).
>>>
>>> Thoughts?
>>>
>>> Thanks,
>>> Kishanthan.
>>> --
>>> *Kishanthan Thangarajah*
>>> Senior Software Engineer,
>>> Platform Technologies Team,
>>> WSO2, Inc.
>>> lean.enterprise.middleware
>>>
>>> Mobile - +94773426635
>>> Blog - *http://kishanthan.wordpress.com
>>> <http://kishanthan.wordpress.com>*
>>> Twitter - *http://twitter.com/kishanthan
>>> <http://twitter.com/kishanthan>*
>>>
>>
>>
>>
>> --
>> *Afkham Azeez*
>> Director of Architecture; WSO2, Inc.; http://wso2.com
>> Member; Apache Software Foundation; http://www.apache.org/
>> * <http://www.apache.org/>*
>> *email: **az...@wso2.com* 
>> * cell: +94 77 3320919 <%2B94%2077%203320919> blog: *
>> *http://blog.afkham.org* <http://blog.afkham.org>
>> *twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
>> * linked-in: **http://lk.linkedin.com/in/afkhamazeez
>> <http://lk.linkedin.com/in/afkhamazeez>*
>>
>> *Lean . Enterprise . Middleware*
>>
>
>
>
> --
> *Kishanthan Thangarajah*
> Senior Software Engineer,
> Platform Technologies Team,
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile - +94773426635
> Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>*
> Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>*
>



-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919 blog: **http://blog.afkham.org*<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
* linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5] Clustering API

[Afkham Azeez]

How about Cluster.getLocalMember().isCoordinator() ?


On Thu, Jan 16, 2014 at 6:40 PM, Sriskandarajah Suhothayan wrote:

> We also need an election API,
>
> E.g for certain tasks only one/few node can be responsible and if that
> node dies some one else need to take that task.
>
> Here user should be able to give the Task Key and should be able to get to
> know whether he is responsible for the task.
>
> It is also impotent that the election logic is pluggable based on task
>
> Regards
> Suho
>
>
> On Thu, Jan 16, 2014 at 4:56 PM, Afkham Azeez  wrote:
>
>>
>>
>>
>> On Thu, Jan 16, 2014 at 4:55 PM, Kishanthan Thangarajah <
>> kishant...@wso2.com> wrote:
>>
>>> Adding more.
>>>
>>> Since we will follow the whiteboard pattern for adding new
>>> MembershipListener's, we don't need to have the methods (
>>> *addMembershipListener, **addMembershipListener*) explicitly at API
>>> level. Users will implement their MembershipListener's and register it as
>>> an OSGi service. The clustering component will discover these and add it
>>> the cluster impl.
>>>
>>>
>> +1
>>
>>
>>
>>>
>>> On Wed, Jan 15, 2014 at 3:03 PM, Afkham Azeez  wrote:
>>>
>>>> Anjana & Suho,
>>>> Please review this & let us know whether these APIs address your
>>>> requirements.
>>>>
>>>> Azeez
>>>>
>>>>
>>>> On Wed, Jan 15, 2014 at 1:40 PM, Kishanthan Thangarajah <
>>>> kishant...@wso2.com> wrote:
>>>>
>>>>> This thread is to discuss about $subject.
>>>>>
>>>>> Our current clustering API's contains stuffs that are mixture of both
>>>>> user level and developer level API. We will have to separate out these 
>>>>> with
>>>>> the clear definition.
>>>>>
>>>>> For clustering API (user level), we will have the following methods.
>>>>> We can discuss clustering SPI's on a separate thread.
>>>>>
>>>>> *void sendMessage(ClusterMessage clusterMessage);*
>>>>>
>>>>> *void sendMessage(ClusterMessage clusterMessage,
>>>>> List members);*
>>>>>
>>>>> *List getMembers();*
>>>>>
>>>>> *void addMembershipListener(MembershipListener
>>>>> membershipListener);*
>>>>>
>>>>> *void removeMembershipListener(MembershipListener
>>>>> membershipListener);*
>>>>>
>>>>> In here we also thought of having MembershipListener (A listener which
>>>>> gets notified when changes occur in Membership) related API at user level.
>>>>> This will be useful when user wants to get some event notification when 
>>>>> the
>>>>> current membership changes. Adding a new MembershipListener will follow 
>>>>> the
>>>>> white board pattern.
>>>>>
>>>>> The API for MembershipListener
>>>>>
>>>>> *void memberAdded(MembershipEvent event);*
>>>>>
>>>>> *void memberRemoved(MembershipEvent event);*
>>>>>
>>>>> MembershipEvent will be of two types (member added or removed).
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Thanks,
>>>>> Kishanthan.
>>>>> --
>>>>> *Kishanthan Thangarajah*
>>>>> Senior Software Engineer,
>>>>> Platform Technologies Team,
>>>>> WSO2, Inc.
>>>>> lean.enterprise.middleware
>>>>>
>>>>> Mobile - +94773426635
>>>>> Blog - *http://kishanthan.wordpress.com
>>>>> <http://kishanthan.wordpress.com>*
>>>>> Twitter - *http://twitter.com/kishanthan
>>>>> <http://twitter.com/kishanthan>*
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> *Afkham Azeez*
>>>> Director of Architecture; WSO2, Inc.; http://wso2.com
>>>> Member; Apache Software Foundation; http://www.apache.org/
>>>> * <http://www.apache.org/>*
>>>> *email: **az...@wso2.com* 
>>>> * cell: +94 77 3320919 <%2B94%2077%203320919> blog: *
>>>> *http://blog.afkham.org* <http://blog.afkham.org>
>>>> *twitter: 
>>>> **http://twitter.com/afk

Re: [Architecture] [C5] Clustering API

[Afkham Azeez]

I think this is making clustering more specific to running tasks. Handling
tasks should be implemented at a layer above clustering.


On Fri, Jan 17, 2014 at 11:06 AM, Sriskandarajah Suhothayan
wrote:

> Based on the Anjana's suggestions, to support different products having
> different way of coordination.
>
> My suggestion is as follows
>
> //This has to be a *one time thing* I'm not sure how we should have API
> for this!
> //ID is Task or GroupID
> //Algorithm-class can be a class or name registered in carbon TBD
> void preformElection(ID, Algorithm-class);
>
> //Register current node to do/join the Task denoted by the ID
> void registerAsTaskWorker(ID);
>
> //Check is the current node is the coordinator
> boolean isCoordinator(ID);
>
> //Get the coordinator for the ID.
> NodeID  getCoordinator(ID);
>
> We also need a Listener for Coordinator
>
> CoordinatorListener
>
>   void coordinatorChanged(ID,NodeID);
>
> WDYT?
>
> Suho
>
>
> On Thu, Jan 16, 2014 at 8:32 PM, Anjana Fernando  wrote:
>
>> Hi,
>>
>> On Thu, Jan 16, 2014 at 5:10 AM, Sriskandarajah Suhothayan > > wrote:
>>
>>> We also need an election API,
>>>
>>> E.g for certain tasks only one/few node can be responsible and if that
>>> node dies some one else need to take that task.
>>>
>>> Here user should be able to give the Task Key and should be able to get
>>> to know whether he is responsible for the task.
>>>
>>> It is also impotent that the election logic is pluggable based on task
>>>
>>
>> The task scenarios are similar to what we do in our scheduled tasks
>> component. I'm not sure if that type of functionality should be included in
>> this API, or did you mean, you need the election API to build on top of it?
>> ..
>>
>> Also, another requirement we have is, creating groups within a cluster.
>> That is, when we work on the cluster, sometimes we need a node a specific
>> group/groups. And it each group will have it's own coordinator. So then,
>> there wouldn't be a single coordinator for the full physical cluster. I
>> know we can build this functionality on a higher layer than this API, but
>> then, effectively the isCoordinator for the full cluster will not be used,
>> and also, each component that uses similar group functionality will roll up
>> their own implementation of this. So I'm thinking if we build in some
>> robust group features to this API itself, it will be very convenient for it
>> consumers.
>>
>> So what I suggest is like, while a member joins for the full cluster
>> automatically, can we have another API method like, joinGroup(groupId),
>> then later when we register a membership listener, we can give the groupId
>> as an optional parameter to register a membership listener for a specific
>> group. And as for the isCoordinator functionality, we can also overload
>> that method to provide a gropuId, or else, in the membership listener
>> itself, we can have an additional method like "coordinatorChanged(String
>> memberId)" or else, maybe more suitable, "assumedCoordinatorRole()" or
>> something like that to simply say, you just became the coordinator of this
>> full cluster/group.
>>
>> Cheers,
>> Anjana.
>>
>>
>>>
>>> Regards
>>> Suho
>>>
>>>
>>> On Thu, Jan 16, 2014 at 4:56 PM, Afkham Azeez  wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Thu, Jan 16, 2014 at 4:55 PM, Kishanthan Thangarajah <
>>>> kishant...@wso2.com> wrote:
>>>>
>>>>> Adding more.
>>>>>
>>>>> Since we will follow the whiteboard pattern for adding new
>>>>> MembershipListener's, we don't need to have the methods (
>>>>> *addMembershipListener, **addMembershipListener*) explicitly at API
>>>>> level. Users will implement their MembershipListener's and register it as
>>>>> an OSGi service. The clustering component will discover these and add it
>>>>> the cluster impl.
>>>>>
>>>>>
>>>> +1
>>>>
>>>>
>>>>
>>>>>
>>>>> On Wed, Jan 15, 2014 at 3:03 PM, Afkham Azeez  wrote:
>>>>>
>>>>>> Anjana & Suho,
>>>>>> Please review this & let us know whether these APIs address your
>>>>>> requirements.
>>>>>>
>>>>>> Azeez
>>>&

[Architecture] Proposed code repository restructuring & move to GitHub

[Afkham Azeez]

mp; features because we
are not changing packages or binary structure. In fact, we would have a P2
repo with compatible features which all work together.

Senaka, Isuruwan & Harshana have already started working on a PoC.

Thoughts welcome. Those who were in these discussions, please add anything
I may have missed.

-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919 blog: **http://blog.afkham.org*<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
* linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] Proposed code repository restructuring & move to GitHub

[Afkham Azeez]

On Fri, Jan 17, 2014 at 9:47 PM, Nirmal Fernando  wrote:

> Huge +1 for the proposed solution. One small question, when you say
> components/features are those imply dependencies (in current terms) as
> well?
>

With respect to orbit bundles, we will create them and immediately upload
them to Nexus. With respected to forked code (dependencies such as
Axis2/Synapse etc. we will need to maintain separate repos. In addition,
forking should be a final resort. Such dependencies will also be uploaded
to Nexus several times a day by Bamboo.


>
>
> On Fri, Jan 17, 2014 at 9:26 PM, Afkham Azeez  wrote:
>
>>  [Sorry for the very long mail. I want to document all that I had in
>> mind & the stuff we discussed. I would recommend all devs to take some time
>> to read this]
>>
>>
>> I would like to summarize he discussion we had a couple of days back.
>>
>> *The Problems*
>> The problems we are trying to solve are as follows:
>>
>> 1. Trunk & branches structures being completely different
>> 2. Branches containing directories with version numbers
>> 3. It is impossible to move to GitHub with the current structure because
>> of #2
>> 4. It is very easy to break the build by changing already released code.
>> The room for human error is high.
>> 5. Bamboo builds are eternally broken because the build fails at some
>> point & Bamboo cannot continue any further
>> 6. When we branch, the trunk quickly becomes obsolete, and remains in
>> that broken state until the next major platform release.
>> 7. Everybody has to build all components/features, even if those are not
>> related to their products
>> 8. Fixed versions in branches instead of using SNAPSHOT versions. This
>> makes it impossible to upload build artifacts to Maven/Nexus repos. This
>> leads to #7.
>> 9. Impossible to integrate code quality tools such as EraInsight because
>> of #5
>>
>> *Proposed solution*
>> We have come up with the following solution after much deliberation &
>> thought.
>>
>> Rationale:
>> We started looking at other open source projects out there. We took Axis2
>> as an example. Axis2 had many dependencies including Axiom, XmlSchema,
>> Woden, WSS4J etc. Those 3rd party dependencies were also developed by some
>> Axis2 contributors, but we never branched all of those together and brought
>> them into the same code branch. We used to start what we used to call a
>> release train, where the upstream code would have to be released first
>> before the downstream code such as Axis2 & Synapse could be released. This
>> way, we never had any of the problems outlined above.
>>
>> If you look at the WSO2 product releases, again, the scenario is not that
>> much different from the Axis2/Synapse releases. Components & features are
>> simply dependencies of the products. In order to get product releases out,
>> we first need releases of those dependencies (components/features). So the
>> proposal is to identify the top level components/features, and first
>> release that code before doing product releases. Each of those components
>> will have a GitHub repo. All active development will be done on the main
>> branch of those components, and will be branched when they are close to the
>> release. Instead of granting commit rights to all, we could only allow the
>> primary developers of those components to commit, and others can send pull
>> requests, which will be merged in by the primary owners after reviewing.
>> These component teams could even have an internal Git repo or clone, and
>> commit to that, run all tests, and when they are satisfied that the code is
>> in a good state to be merged into the main branch, they can send a pull
>> request & merge the changes. We would run Bamboo which would build the
>> components several times a day & deploy them to the Nexus repo. That way,
>> you would not have to build code that is not directly related to what you
>> are working on, which would save 100s of valuable dev hours.
>>
>> In the majority of the cases, the P2 features correspond to one or more
>> related components. So we would keep the feature close to the component.
>> There are some cases where these components & features belong in the
>> product itself. AppFactory components are a good example.
>>
>> Products will also have their own GitHub repos. We will have separate
>> GitHub repos for platform integration tests. Products such as API Manager
>> may opt to have the API Management feature in the product itself. We would
>> have a separate P2-repo GitHub repo which

Re: [Architecture] [C5] Clustering API

[Afkham Azeez]

On Fri, Jan 17, 2014 at 10:42 PM, Anjana Fernando  wrote:

> Hi,
>
> Yeah, most probably, the task related functionality should not be part of
> this API, but the group functionality I mentioned *could* be useful, as I
> explained.
>

The golden rule about API design is "when in doubt, leave it out" (
http://www.infoq.com/articles/API-Design-Joshua-Bloch)


>
> Cheers,
> Anjana.
>
>
> On Fri, Jan 17, 2014 at 4:08 AM, Kishanthan Thangarajah <
> kishant...@wso2.com> wrote:
>
>> IMO, I think task related APIs are not part of kernel or clustering APIs
>> provided by the kernel. Since this is more of a use-case on functions
>> provided by the hazelcast, we can expose the underline hazelcast instance
>> as an OSGi service which then can be used for the above purpose.
>>
>>
>> On Fri, Jan 17, 2014 at 12:42 PM, Sriskandarajah Suhothayan <
>> s...@wso2.com> wrote:
>>
>>> I'm OK to have a separate API to handle the task stuff, but in that case
>>> will it have access to Hazelcast or other internal stuff?
>>> and should it be a part of kernel ?
>>>
>>> I'm not sure what are the bits and pieces we need from Hazelcast to
>>> create this API and exposing all of them will make the Caching API ugly :)
>>>
>>> Regards,
>>> Suho
>>>
>>>
>>>
>>>
>>> On Fri, Jan 17, 2014 at 11:44 AM, Supun Malinga  wrote:
>>>
>>>> Hi,
>>>>
>>>> Also in here we should consider the use cases of OC as well IMO..
>>>>
>>>>  thanks,
>>>>
>>>>
>>>> On Fri, Jan 17, 2014 at 11:24 AM, Afkham Azeez  wrote:
>>>>
>>>>> I think this is making clustering more specific to running tasks.
>>>>> Handling tasks should be implemented at a layer above clustering.
>>>>>
>>>>>
>>>>> On Fri, Jan 17, 2014 at 11:06 AM, Sriskandarajah Suhothayan <
>>>>> s...@wso2.com> wrote:
>>>>>
>>>>>> Based on the Anjana's suggestions, to support different products
>>>>>> having different way of coordination.
>>>>>>
>>>>>> My suggestion is as follows
>>>>>>
>>>>>> //This has to be a *one time thing* I'm not sure how we should have
>>>>>> API for this!
>>>>>> //ID is Task or GroupID
>>>>>> //Algorithm-class can be a class or name registered in carbon TBD
>>>>>> void preformElection(ID, Algorithm-class);
>>>>>>
>>>>>> //Register current node to do/join the Task denoted by the ID
>>>>>> void registerAsTaskWorker(ID);
>>>>>>
>>>>>> //Check is the current node is the coordinator
>>>>>> boolean isCoordinator(ID);
>>>>>>
>>>>>> //Get the coordinator for the ID.
>>>>>> NodeID  getCoordinator(ID);
>>>>>>
>>>>>> We also need a Listener for Coordinator
>>>>>>
>>>>>> CoordinatorListener
>>>>>>
>>>>>>   void coordinatorChanged(ID,NodeID);
>>>>>>
>>>>>> WDYT?
>>>>>>
>>>>>> Suho
>>>>>>
>>>>>>
>>>>>> On Thu, Jan 16, 2014 at 8:32 PM, Anjana Fernando wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Thu, Jan 16, 2014 at 5:10 AM, Sriskandarajah Suhothayan <
>>>>>>> s...@wso2.com> wrote:
>>>>>>>
>>>>>>>> We also need an election API,
>>>>>>>>
>>>>>>>> E.g for certain tasks only one/few node can be responsible and if
>>>>>>>> that node dies some one else need to take that task.
>>>>>>>>
>>>>>>>> Here user should be able to give the Task Key and should be able to
>>>>>>>> get to know whether he is responsible for the task.
>>>>>>>>
>>>>>>>> It is also impotent that the election logic is pluggable based on
>>>>>>>> task
>>>>>>>>
>>>>>>>
>>>>>>> The task scenarios are similar to what we do in our scheduled tasks
>>>>>>> component. I'm not sure if that type of functionality should be 
>>>>>&g

Re: [Architecture] Proposed code repository restructuring & move to GitHub

[Afkham Azeez]

One more thing. More unit tests should be added to components, rather than
relying on integration tests only. The integration tests require the
availability of a runtime, which is very cumbersome. This is also a case
where mocks can be used extensively.

Azeez


On Fri, Jan 17, 2014 at 9:26 PM, Afkham Azeez  wrote:

> [Sorry for the very long mail. I want to document all that I had in mind &
> the stuff we discussed. I would recommend all devs to take some time to
> read this]
>
>
> I would like to summarize he discussion we had a couple of days back.
>
> *The Problems*
> The problems we are trying to solve are as follows:
>
> 1. Trunk & branches structures being completely different
> 2. Branches containing directories with version numbers
> 3. It is impossible to move to GitHub with the current structure because
> of #2
> 4. It is very easy to break the build by changing already released code.
> The room for human error is high.
> 5. Bamboo builds are eternally broken because the build fails at some
> point & Bamboo cannot continue any further
> 6. When we branch, the trunk quickly becomes obsolete, and remains in that
> broken state until the next major platform release.
> 7. Everybody has to build all components/features, even if those are not
> related to their products
> 8. Fixed versions in branches instead of using SNAPSHOT versions. This
> makes it impossible to upload build artifacts to Maven/Nexus repos. This
> leads to #7.
> 9. Impossible to integrate code quality tools such as EraInsight because
> of #5
>
> *Proposed solution*
> We have come up with the following solution after much deliberation &
> thought.
>
> Rationale:
> We started looking at other open source projects out there. We took Axis2
> as an example. Axis2 had many dependencies including Axiom, XmlSchema,
> Woden, WSS4J etc. Those 3rd party dependencies were also developed by some
> Axis2 contributors, but we never branched all of those together and brought
> them into the same code branch. We used to start what we used to call a
> release train, where the upstream code would have to be released first
> before the downstream code such as Axis2 & Synapse could be released. This
> way, we never had any of the problems outlined above.
>
> If you look at the WSO2 product releases, again, the scenario is not that
> much different from the Axis2/Synapse releases. Components & features are
> simply dependencies of the products. In order to get product releases out,
> we first need releases of those dependencies (components/features). So the
> proposal is to identify the top level components/features, and first
> release that code before doing product releases. Each of those components
> will have a GitHub repo. All active development will be done on the main
> branch of those components, and will be branched when they are close to the
> release. Instead of granting commit rights to all, we could only allow the
> primary developers of those components to commit, and others can send pull
> requests, which will be merged in by the primary owners after reviewing.
> These component teams could even have an internal Git repo or clone, and
> commit to that, run all tests, and when they are satisfied that the code is
> in a good state to be merged into the main branch, they can send a pull
> request & merge the changes. We would run Bamboo which would build the
> components several times a day & deploy them to the Nexus repo. That way,
> you would not have to build code that is not directly related to what you
> are working on, which would save 100s of valuable dev hours.
>
> In the majority of the cases, the P2 features correspond to one or more
> related components. So we would keep the feature close to the component.
> There are some cases where these components & features belong in the
> product itself. AppFactory components are a good example.
>
> Products will also have their own GitHub repos. We will have separate
> GitHub repos for platform integration tests. Products such as API Manager
> may opt to have the API Management feature in the product itself. We would
> have a separate P2-repo GitHub repo which would build & deploy the
> compatible set of P2 features.
>
> We will have Bamboo plans at multiple levels; components, products,
> platform, p2-repo and so on.
>
> We will not change any package structures at this time. We would defer
> that to Carbon 5 (if necessary). We will get rid of the chunk based release
> model. Continuous delivery is our ultimate aim & for that to happen, we
> have to release a compatible set of features. We are going to rely heavily
> on automation, automated builds & deploys to Maven. The developers will do
> t

Re: [Architecture] Proposed code repository restructuring & move to GitHub

[Afkham Azeez]

Under dependency governance, the plan is to show the dependency graph, so
that when an upstream dependency changes, we would know what downstream
code would be affected.


On Sat, Jan 18, 2014 at 9:50 PM, Hasitha Hiranya  wrote:

> Hi,
>
> +1 for the categorization.
> Is there a way to make a Tree graph or something displaying
> the dependency graph? And maintain it somewhere? In that way in the long
> run we will have a clear visibility (when new components/features added).
>
> Thanks
>
>
> On Sat, Jan 18, 2014 at 6:30 PM, Eranda Sooriyabandara wrote:
>
>> Hi All,
>> Here is the component categorization.
>>
>> Remove forever
>>
>>- qpid
>>- rest-api
>>- mashup
>>
>> Need to move to relevent products
>>
>>- stratos
>>- cloud-controller
>>- appfac
>>- ec2-client
>>- cg
>>
>>
>> Graduate to nexus
>>
>>- mapred
>>- email-verification
>>- captcha-mgt
>>- tryit
>>- wsdlvalidator
>>- java2wsdl
>>- soap-tracer
>>- zeroconf
>>- wsdl2code
>>- wsdl2form
>>- schema-generator
>>
>>
>> carbon-feature-registry
>>
>>- registry
>>
>>
>> carbon-feature-governance
>>
>>- governance
>>
>>
>> carbon-feature-identity
>>
>>
>>- identity
>>- authenticators
>>- claim-mgt
>>- remote-usermgt
>>- user-manager
>>- user-stores
>>- sts
>>- policy-builder
>>- policy-editor
>>- security
>>- directory-server-manager
>>- idp-mgt
>>- ldap-server
>>- profile-mgt
>>- cassandra-userstore
>>- issue-tracker
>>
>>
>> carbon-feature-mediation
>>
>>- mediation
>>- mediation-initializer
>>- mediation-statistics
>>- mediation-tracer
>>- mediators
>>- messagebox
>>- message-relay
>>- mex
>>- priority-mediation
>>- sequence-editor
>>- synapse-artifact-uploader
>>- synapse-config-admin
>>- synapse-registries
>>- proxy-admin
>>- localentry
>>- endpoint
>>- view-flows
>>- xfer
>>- xkms
>>
>>
>> carbon-feature-analytics
>>
>>- analytics
>>- bam2
>>- data-agents
>>- transport-statistics
>>- system-statistics
>>- dashboard
>>- dashboard2
>>- gadget-ide
>>- gadgets
>>- gauges
>>- health-monitor
>>
>>
>>
>> carbon-feature-data
>>
>>- data-services
>>- dbconsole
>>- data-sources
>>- ndatasource
>>
>>
>> carbon-feature-apis
>>
>>- apimgt
>>- appmgt
>>
>>
>> carbon-feature-business-process
>>
>>- business-processes
>>- multiple-instance
>>- coordination
>>
>> carbon-feature-business-messaging
>>
>>- business-messaging
>>- event
>>- eventing
>>- event-processing
>>
>>
>> carbon-feature-rules
>>
>>- rule
>>
>>
>> carbon-feature-deployment
>>
>>- webapp-mgt
>>- jaxws
>>- module-mgt
>>- service-mgt
>>- spring-services
>>- application-deployers
>>- application-mgt
>>- axis2-repo-mgt
>>- ejb-services
>>- aar-services
>>- jar-services
>>- autoscaler
>>- load-balancer
>>- deployment-synchronizer
>>
>>
>> carbon-feature-qos
>>
>>- throttling
>>- reliable-messaging
>>
>>
>> carbon-feature-utils
>>
>>- caching
>>- cluster-mgt
>>- unified-endpoint
>>- url-mapper
>>- ws-discovery
>>- rss-manager
>>- transaction-manager
>>- transport-mgt
>>- transports
>>- jaggery
>>- hostobjects
>>- ntask
>>- scheduled-tasks
>>    - operation-mgt
>>- startup
>>- reporting
>>- data-bridge
>>- doc-request-processor
>>- logging
>>- admin-mgt
>>- remote-tasks
>>- andes
>>- cassandra
>>- cassandra-explorer
>>- cassandra-search
>>- hdfs
>>
>>
>> When adding a component to a project please note the following.
>>
>>1. utils project should be not

Re: [Architecture] [C5] Clustering SPI

[Afkham Azeez]

On Sun, Jan 19, 2014 at 3:11 PM, Isuru Perera  wrote:

> How about following change?
>
> s/ClusteringFault/ClusteringException
>


Yes, no more Fault in exception names. Those exception names were inspired
by SOAP. In addition, instead of ClusteringException, we need to have some
specific types; e.g. ClusterInitializationException, MessageFailedException
etc.


>
>
>
> On Sun, Jan 19, 2014 at 11:40 AM, Kishanthan Thangarajah <
> kishant...@wso2.com> wrote:
>
>> Clustering SPI provides the ability to plug-in different clustering
>> implementation to carbon. By default, carbon will ship hazel-cast based
>> clustering impl. There will be a separate file (cluster.xml) for cluster
>> configuration.
>>
>> The SPI will contain the following main interfaces.
>>
>> *ClusteringAgent* - is responsible for initializing and managing this
>> node in the cluster.
>> *MembershipScheme* - a representation of a membership scheme such as
>> "multicast" or "well-known address (wka) used in the cluster.
>>
>> A high-level view can be as follows
>>
>> [image: Inline image 1]
>>
>> When the cluster agent is successfully initialized, it will also register
>> the Cluster Service (being discussed at "[C5] Clustering API"). The
>> Cluster Service will use the clustering agent underneath at implementation
>> level for its required operations. Based on previous experiences, we have
>> defined the following methods for clustering agent and membership scheme
>> for now. Based on the final outcome of this discussion, they may get
>> changed.
>>
>> *ClusteringAgent*
>>
>> /**
>>  * Initialize the agent which will initialize this node, and join the
>> cluster
>>  */
>> void *init*() throws ClusteringFault;
>>
>> /**
>>  * Shutdown the agent which will remove this node from cluster
>>  */
>> void *shutdown*() throws ClusteringFault;
>>
>> /**
>>  * Set carbon configuration context to this agent to be used in the
>> clustering impl
>>  */
>> void *setConfigurationContext*(CarbonConfigurationContext
>> configurationContext);
>>
>> /**
>>  * Get the list of static members
>>  */
>> List *getStaticMembers*();
>>
>> /**
>>  * Get the number of members alive.
>>  */
>> int *getAliveMemberCount*();
>>
>> /**
>>  * Send a message to all members in the cluster
>>  */
>> List *sendMessage*(ClusterMessage msg, boolean
>> isSync)
>> throws ClusteringFault;
>>
>> /**
>>  * Send a message to a set of specific members in the cluster
>>  */
>> List *sendMessage*(ClusterMessage msg,
>> List members, boolean isSync)
>> throws ClusteringFault;
>>
>>
>> *MembershipScheme*
>>
>> void *init*() throws ClusteringFault;
>>
>> void *joinGroup*() throws ClusteringFault;
>>
>>
>> Thoughts?
>>
>> Thanks,
>> Kishanthan.
>> --
>>  *Kishanthan Thangarajah*
>> Senior Software Engineer,
>> Platform Technologies Team,
>> WSO2, Inc.
>> lean.enterprise.middleware
>>
>> Mobile - +94773426635
>> Blog - *http://kishanthan.wordpress.com
>> <http://kishanthan.wordpress.com>*
>> Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>*
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Isuru Perera
> Senior Software Engineer | WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> about.me/chrishantha
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919 blog: **http://blog.afkham.org*<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
* linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
<>___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Proposed code repository restructuring & move to GitHub

[Afkham Azeez]

ializer
>>>- mediation-statistics
>>>- mediation-tracer
>>>- mediators
>>>- messagebox
>>>- message-relay
>>>- mex
>>>- priority-mediation
>>>- sequence-editor
>>>- synapse-artifact-uploader
>>>- synapse-config-admin
>>>- synapse-registries
>>>- proxy-admin
>>>- localentry
>>>- endpoint
>>>- view-flows
>>>- xfer
>>>- xkms
>>>
>>>
>>> carbon-feature-analytics
>>>
>>>- analytics
>>>- bam2
>>>- data-agents
>>>- transport-statistics
>>>- system-statistics
>>>- dashboard
>>>- dashboard2
>>>- gadget-ide
>>>- gadgets
>>>- gauges
>>>- health-monitor
>>>
>>>
>>>
>>> carbon-feature-data
>>>
>>>- data-services
>>>- dbconsole
>>>- data-sources
>>>- ndatasource
>>>
>>>
>>> carbon-feature-apis
>>>
>>>- apimgt
>>>- appmgt
>>>
>>>
>>> carbon-feature-business-process
>>>
>>>- business-processes
>>>- multiple-instance
>>>- coordination
>>>
>>> carbon-feature-business-messaging
>>>
>>>- business-messaging
>>>- event
>>>- eventing
>>>- event-processing
>>>
>>>
>>> carbon-feature-rules
>>>
>>>- rule
>>>
>>>
>>>
>>
>>> carbon-feature-deployment
>>>
>>
>> We should remove jaxws component too. This component was added for Axis2
>> based jax-ws support. We don't use it anymore.
>>
>
> Will do it.
>
>>
>>
>> Thanks,
>> KasunG
>>
>>>
>>>- webapp-mgt
>>>- jaxws
>>>- module-mgt
>>>    - service-mgt
>>>- spring-services
>>>- application-deployers
>>>- application-mgt
>>>- axis2-repo-mgt
>>>- ejb-services
>>>- aar-services
>>>- jar-services
>>>- autoscaler
>>>- load-balancer
>>>- deployment-synchronizer
>>>
>>>
>>> carbon-feature-qos
>>>
>>>- throttling
>>>- reliable-messaging
>>>
>>>
>>> carbon-feature-utils
>>>
>>>- caching
>>>- cluster-mgt
>>>- unified-endpoint
>>>- url-mapper
>>>- ws-discovery
>>>- rss-manager
>>>- transaction-manager
>>>- transport-mgt
>>>- transports
>>>- jaggery
>>>- hostobjects
>>>- ntask
>>>- scheduled-tasks
>>>- operation-mgt
>>>- startup
>>>- reporting
>>>- data-bridge
>>>- doc-request-processor
>>>- logging
>>>- admin-mgt
>>>- remote-tasks
>>>- andes
>>>- cassandra
>>>- cassandra-explorer
>>>- cassandra-search
>>>- hdfs
>>>
>>>
>>> When adding a component to a project please note the following.
>>>
>>>1. utils project should be not depend on any other projects. Any
>>>other project can depend on another project but it shouldn't be cyclic.
>>>2. If any component is not going to change we can graduate to the
>>>nexus without making everyone to build the source. I have identified
>>>certain components, but if you think it source will be changed then we
>>>still can add it to the related project.
>>>
>>> Your comments and suggestions are mostly welcome. Project leads please
>>> confirm the structure.
>>>
>>>
>>> thanks
>>> Eranda
>>>
>>>
>>>
>>> On Sat, Jan 18, 2014 at 11:09 AM, Eranda Sooriyabandara >> > wrote:
>>>
>>> Hi Sagara,
>>>
>>>
>>> On Sat, Jan 18, 2014 at 11:02 AM, Sagara Gunathunga wrote:
>>>
>>>
>>>
>>>
>>> On Sat, Jan 18, 2014 at 10:31 AM, Afkham Azeez  wrote:
>>>
>>> Shall we name those as;
>>>
>>>- carbon-feature-registry
>>>- carbon-feature-governance
>>>- carbon-feature-identity
>>>- carbon-feature-mediation
>>>- carbon-

Re: [Architecture] Proposed code repository restructuring & move to GitHub

[Afkham Azeez]

On Sun, Jan 19, 2014 at 11:34 PM, Sameera Jayasoma  wrote:

>
>
>
> On Sun, Jan 19, 2014 at 9:53 AM, Selvaratnam Uthaiyashankar <
> shan...@wso2.com> wrote:
>
>>
>>
>>
>> On Sun, Jan 19, 2014 at 11:02 PM, Sameera Jayasoma wrote:
>>
>>> Hi Azeez,
>>>
>>> +1 for this model. This will solve most of the issues that we are facing
>>> in the current system.
>>>
>>>
>>> Senaka, see my comment below.
>>>
>>> On Sat, Jan 18, 2014 at 10:48 AM, Senaka Fernando wrote:
>>>
>>>> Hi Azeez, Eranda,
>>>>
>>>> +1 for the proposed changes. So, as discussed we have two options.
>>>>
>>>> 1. In the git repo, go for wso2/carbon/feature or wso2/carbon/product
>>>> model and then have features such as registry, governance and products such
>>>> as esb.
>>>>
>>>
>>>
>>> I am + for the Option 1 if possible.
>>>
>>
>>
>> With this option, shouldn't we checkout the whole components? AFAIK, GIt
>> doesn't support checking out part of the repo. Also, the release, branching
>> etc. will be at the repo level, can't be at a sub repo level. Above
>> structure is what we have now and is the reason for most of the trouble we
>> are having, isn't it?
>>
>
> No Shankar, all the components will be separate projects on their own. But
> this is just a matter of organizing them in a proper order without putting
> everything to the top level. (only if this is possible.)
>
> e.g. https://github.com/wso2/carbon/components/identity
>

You can't do that. It will create your repo as, carbon-components-identity
if you try to do that.


>
> If this is not possible, then I prefer *carbon-component-* instead of
> carbon-feature-*. * Because IMHO, components are what we develop and
> features are just a way of installing these components to projects. We may
> end up multiple features for a given component or features which combine
> multiple components.
>
>
>
>>
>>
>>
>>>  That will allows developers to easily navigate to the relevant
>>> component.
>>>
>>> How about using wso2/carbon/components instead of features. What we
>>> really develop is components? I would prefer to use the word component
>>> rather than using the word feature.
>>>
>>> WDYT?
>>>
>>>
>>>>  2. Go with the model Azeez wrote in e-mail.
>>>>
>>>
>>> With option 2, we will end up with many top level projects under wso2/.
>>>
>>>>
>>>> We need to figure out whether git supports #1 and if not go for #2.
>>>>
>>>> Also, wanted to highlight that we will no longer have service-stubs,
>>>> and separate features categories. There will be no concept of parent, since
>>>> each feature will define its own dependencies *excluding transitive
>>>> dependencies*. The development governance system that we put in place
>>>> will ensure we reuse the same versions and a separate pom is unwanted.
>>>>
>>>> Further, all branched dependencies and orbits will reside outside of
>>>> our code structure, and those should follow separate release models as
>>>> discussed previously.
>>>>
>>>> Next, we will integrate GerritHub for code reviews.
>>>>
>>>> Thanks,
>>>> Senaka.
>>>>
>>>> On Sat, Jan 18, 2014 at 10:31 AM, Afkham Azeez  wrote:
>>>>
>>>>> Shall we name those as;
>>>>>
>>>>>- carbon-feature-registry
>>>>>- carbon-feature-governance
>>>>>- carbon-feature-identity
>>>>>- carbon-feature-mediation
>>>>>- carbon-feature-analytics
>>>>>- carbon-feature-data
>>>>>- carbon-feature-apis
>>>>>- carbon-feature-business-process
>>>>>- carbon-feature-business-messaging
>>>>>- carbon-feature-rules
>>>>>- carbon-feature-deployment
>>>>>- carbon-feature-qos
>>>>>- carbon-feature-utils
>>>>>
>>>>> and also have;
>>>>> * carbon-product-appserver
>>>>> * carbon-product-esb
>>>>>
>>>>> and so on.
>>>>>
>>>>> Also;
>>>>> carbon-p2-repo
>>>>>
>>>>> carbon-platform-integration-tests
>>>>>
>>

Re: [Architecture] [C5] Clustering SPI

[Afkham Azeez]

Most of these methods are from the old clustering API. We can get rid of
some of them such as getAliveMemberCount. Also, isSync indicates that it is
a blocking message sending where a response can be received on the same
channel. We cannot generically implement that with all clustering
frameworks, so let's drop the isSync param. We are not using it anyway with
the current Hazelcast based implementation.

Azeez


On Sun, Jan 19, 2014 at 11:32 PM, Selvaratnam Uthaiyashankar <
shan...@wso2.com> wrote:

>
>
>
> On Sun, Jan 19, 2014 at 11:40 AM, Kishanthan Thangarajah <
> kishant...@wso2.com> wrote:
>
>> Clustering SPI provides the ability to plug-in different clustering
>> implementation to carbon. By default, carbon will ship hazel-cast based
>> clustering impl. There will be a separate file (cluster.xml) for cluster
>> configuration.
>>
>> The SPI will contain the following main interfaces.
>>
>> *ClusteringAgent* - is responsible for initializing and managing this
>> node in the cluster.
>> *MembershipScheme* - a representation of a membership scheme such as
>> "multicast" or "well-known address (wka) used in the cluster.
>>
>> A high-level view can be as follows
>>
>> [image: Inline image 1]
>>
>> When the cluster agent is successfully initialized, it will also register
>> the Cluster Service (being discussed at "[C5] Clustering API"). The
>> Cluster Service will use the clustering agent underneath at implementation
>> level for its required operations. Based on previous experiences, we have
>> defined the following methods for clustering agent and membership scheme
>> for now. Based on the final outcome of this discussion, they may get
>> changed.
>>
>> *ClusteringAgent*
>>
>> /**
>>  * Initialize the agent which will initialize this node, and join the
>> cluster
>>  */
>> void *init*() throws ClusteringFault;
>>
>> /**
>>  * Shutdown the agent which will remove this node from cluster
>>  */
>> void *shutdown*() throws ClusteringFault;
>>
>> /**
>>  * Set carbon configuration context to this agent to be used in the
>> clustering impl
>>  */
>> void *setConfigurationContext*(CarbonConfigurationContext
>> configurationContext);
>>
>> /**
>>  * Get the list of static members
>>  */
>> List *getStaticMembers*();
>>
>
>
>
> Don't we need a method to get all the members (including dynamic members)?
>
>
>
>>
>> /**
>>  * Get the number of members alive.
>>  */
>> int *getAliveMemberCount*();
>>
>> /**
>>  * Send a message to all members in the cluster
>>  */
>> List *sendMessage*(ClusterMessage msg, boolean
>> isSync)
>> throws ClusteringFault;
>>
>
>
> what is "isSync"? Synchronous communication? or are we synchronizing
> something?
>
>  Also, what are the contents of ClusteringCommand?
>
>
>
>>
>> /**
>>  * Send a message to a set of specific members in the cluster
>>  */
>> List *sendMessage*(ClusterMessage msg,
>> List members, boolean isSync)
>> throws ClusteringFault;
>>
>>
>> *MembershipScheme*
>>
>> void *init*() throws ClusteringFault;
>>
>> void *joinGroup*() throws ClusteringFault;
>>
>>
>> Thoughts?
>>
>> Thanks,
>> Kishanthan.
>> --
>>  *Kishanthan Thangarajah*
>> Senior Software Engineer,
>> Platform Technologies Team,
>> WSO2, Inc.
>> lean.enterprise.middleware
>>
>> Mobile - +94773426635
>> Blog - *http://kishanthan.wordpress.com
>> <http://kishanthan.wordpress.com>*
>> Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>*
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> S.Uthaiyashankar
> VP Engineering
> WSO2 Inc.
> http://wso2.com/ - "lean . enterprise . middleware"
>
> Phone: +94 714897591
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919 blog: **http://blog.afkham.org*<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
* linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
<>___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Proper way of patching an OSGi bundle (without restarting the runtime)?

[Afkham Azeez]

Folks,
Our patching strategy has been to make an exact copy of the patched jar,
and then during startup, do a bundle replacement.

With Carbon 5, our aim is to be able to patch bundles without requiring a
full restart of the OSGi runtime. I read somewhere that;

update  file:patches/


is one way of patching a bundle.

So say we are patching org.wso2.carbon.core-4.2.0.jar, we could have a
patched jar called org.wso2.carbon.core-4.2.0.p0001.jar and then do;

update 23 file:patches/p0001/org.wso2.carbon.core-4.2.0.p0001.jar



Will this strategy work?

-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919 blog: **http://blog.afkham.org*<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
* linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] Proper way of patching an OSGi bundle (without restarting the runtime)?

[Afkham Azeez]

Yes, you have to refresh the dependent bundles. I think we can write our
patching logic to figure out the OSGi wiring (using OSGi WireAdmin) and
then refresh the dependent bundles.


On Mon, Jan 20, 2014 at 11:18 PM, Shameera Rathnayaka wrote:

> Hi Azeez,
>
> As we know in OSGi world we have tow types of dependencies 1) OSGi
> services, 2) Bundle wiring . updating a bundle with new bundle we can solve
> OSGi services dependencies correctly but when we come to bundle wiring we
> need to find out correct dependency closure and refresh that OSGi bundles.
> If not the bundle which already wired with old bundle will not get wired
> with the update osgi bundle. Hence we need to carefully thing about this
> process.
>
> Thanks,
> Shameera.
>
> n Mon, Jan 20, 2014 at 7:42 PM, Afkham Azeez  wrote:
>
>> Folks,
>> Our patching strategy has been to make an exact copy of the patched jar,
>> and then during startup, do a bundle replacement.
>>
>> With Carbon 5, our aim is to be able to patch bundles without requiring a
>> full restart of the OSGi runtime. I read somewhere that;
>>
>>
>> update  file:patches/
>>
>>
>> is one way of patching a bundle.
>>
>> So say we are patching org.wso2.carbon.core-4.2.0.jar, we could have a
>> patched jar called org.wso2.carbon.core-4.2.0.p0001.jar and then do;
>>
>>
>> update 23 file:patches/p0001/org.wso2.carbon.core-4.2.0.p0001.jar
>>
>>
>>
>> Will this strategy work?
>>
>> --
>> *Afkham Azeez*
>> Director of Architecture; WSO2, Inc.; http://wso2.com
>> Member; Apache Software Foundation; http://www.apache.org/
>> * <http://www.apache.org/>*
>> *email: **az...@wso2.com* 
>> * cell: +94 77 3320919 <%2B94%2077%203320919> blog: *
>> *http://blog.afkham.org* <http://blog.afkham.org>
>> *twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
>> * linked-in: **http://lk.linkedin.com/in/afkhamazeez
>> <http://lk.linkedin.com/in/afkhamazeez>*
>>
>> *Lean . Enterprise . Middleware*
>>
>> ___
>> Dev mailing list
>> d...@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> *Software Engineer - WSO2 Inc.*
> *email: shameera AT wso2.com  , shameera AT apache.org
> *
> *phone:  +9471 922 1454 <%2B9471%20922%201454>*
>
> *Linked in : *http://lk.linkedin.com/pub/shameera-rathnayaka/1a/661/561
> *Twitter : *https://twitter.com/Shameera_R
>



-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919 blog: **http://blog.afkham.org*<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
* linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] Proper way of patching an OSGi bundle (without restarting the runtime)?

[Afkham Azeez]

With regards to patches including config file changes, we should make it
possible to hot update config files. Stratos folks are doing this
(somewhat) successfully. The partitions, autoscaling policy etc. are hot
updated.


On Tue, Jan 21, 2014 at 7:52 AM, Afkham Azeez  wrote:

> Yes, you have to refresh the dependent bundles. I think we can write our
> patching logic to figure out the OSGi wiring (using OSGi WireAdmin) and
> then refresh the dependent bundles.
>
>
> On Mon, Jan 20, 2014 at 11:18 PM, Shameera Rathnayaka 
> wrote:
>
>> Hi Azeez,
>>
>> As we know in OSGi world we have tow types of dependencies 1) OSGi
>> services, 2) Bundle wiring . updating a bundle with new bundle we can solve
>> OSGi services dependencies correctly but when we come to bundle wiring we
>> need to find out correct dependency closure and refresh that OSGi bundles.
>> If not the bundle which already wired with old bundle will not get wired
>> with the update osgi bundle. Hence we need to carefully thing about this
>> process.
>>
>> Thanks,
>> Shameera.
>>
>> n Mon, Jan 20, 2014 at 7:42 PM, Afkham Azeez  wrote:
>>
>>> Folks,
>>> Our patching strategy has been to make an exact copy of the patched jar,
>>> and then during startup, do a bundle replacement.
>>>
>>> With Carbon 5, our aim is to be able to patch bundles without requiring
>>> a full restart of the OSGi runtime. I read somewhere that;
>>>
>>>
>>> update  file:patches/
>>>
>>>
>>> is one way of patching a bundle.
>>>
>>> So say we are patching org.wso2.carbon.core-4.2.0.jar, we could have a
>>> patched jar called org.wso2.carbon.core-4.2.0.p0001.jar and then do;
>>>
>>>
>>> update 23 file:patches/p0001/org.wso2.carbon.core-4.2.0.p0001.jar
>>>
>>>
>>>
>>> Will this strategy work?
>>>
>>> --
>>> *Afkham Azeez*
>>> Director of Architecture; WSO2, Inc.; http://wso2.com
>>> Member; Apache Software Foundation; http://www.apache.org/
>>> * <http://www.apache.org/>*
>>> *email: **az...@wso2.com* 
>>> * cell: +94 77 3320919 <%2B94%2077%203320919> blog: *
>>> *http://blog.afkham.org* <http://blog.afkham.org>
>>> *twitter: 
>>> **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
>>> * linked-in: **http://lk.linkedin.com/in/afkhamazeez
>>> <http://lk.linkedin.com/in/afkhamazeez>*
>>>
>>> *Lean . Enterprise . Middleware*
>>>
>>> ___
>>> Dev mailing list
>>> d...@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> *Software Engineer - WSO2 Inc.*
>> *email: shameera AT wso2.com  , shameera AT apache.org
>> *
>> *phone:  +9471 922 1454 <%2B9471%20922%201454>*
>>
>> *Linked in : *http://lk.linkedin.com/pub/shameera-rathnayaka/1a/661/561
>> *Twitter : *https://twitter.com/Shameera_R
>>
>
>
>
> --
> *Afkham Azeez*
> Director of Architecture; WSO2, Inc.; http://wso2.com
> Member; Apache Software Foundation; http://www.apache.org/
> * <http://www.apache.org/>*
> *email: **az...@wso2.com* 
> * cell: +94 77 3320919 <%2B94%2077%203320919> blog: *
> *http://blog.afkham.org* <http://blog.afkham.org>
> *twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
> * linked-in: **http://lk.linkedin.com/in/afkhamazeez
> <http://lk.linkedin.com/in/afkhamazeez>*
>
> *Lean . Enterprise . Middleware*
>



-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919 blog: **http://blog.afkham.org*<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
* linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] Proper way of patching an OSGi bundle (without restarting the runtime)?

[Afkham Azeez]

With C5, our dependency on Axis2 will be minimal.

Azeez


On Mon, Jan 20, 2014 at 7:59 PM, Kasun Gajasinghe  wrote:

> Hi Azeez,
>
> I have used the said method of updating a bundle, and it worked for me
> sometimes. But there can be issues when doing this. One issue I have faced
> is that, if a bundle contained an admin service, then that service gets
> re-added during a bundle update. Then, Axis2 started complaining two
> services cannot have the same name.
>
> The said issue won't be there in C5 since we will not be using axis2 based
> admin services. But there can be other issues like this when the
> initialization logic happens inside the service component. IMO it's better
> to do a restart of the server for bundle updates.
>
> Thanks,
> KasunG
>
>
> On Mon, Jan 20, 2014 at 7:42 PM, Afkham Azeez  wrote:
>
>> Folks,
>> Our patching strategy has been to make an exact copy of the patched jar,
>> and then during startup, do a bundle replacement.
>>
>> With Carbon 5, our aim is to be able to patch bundles without requiring a
>> full restart of the OSGi runtime. I read somewhere that;
>>
>>
>> update  file:patches/
>>
>>
>> is one way of patching a bundle.
>>
>> So say we are patching org.wso2.carbon.core-4.2.0.jar, we could have a
>> patched jar called org.wso2.carbon.core-4.2.0.p0001.jar and then do;
>>
>>
>> update 23 file:patches/p0001/org.wso2.carbon.core-4.2.0.p0001.jar
>>
>>
>>
>> Will this strategy work?
>>
>> --
>> *Afkham Azeez*
>> Director of Architecture; WSO2, Inc.; http://wso2.com
>> Member; Apache Software Foundation; http://www.apache.org/
>> * <http://www.apache.org/>*
>> *email: **az...@wso2.com* 
>> * cell: +94 77 3320919 <%2B94%2077%203320919> blog: *
>> *http://blog.afkham.org* <http://blog.afkham.org>
>> *twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
>> * linked-in: **http://lk.linkedin.com/in/afkhamazeez
>> <http://lk.linkedin.com/in/afkhamazeez>*
>>
>> *Lean . Enterprise . Middleware*
>>
>> ___
>> Dev mailing list
>> d...@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>


-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919 blog: **http://blog.afkham.org*<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
* linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Proposed code repository restructuring & move to GitHub

[Afkham Azeez]

Yes, we had a discussion about this, and it seemed to be quite cumbersome
to preserve the SVN history. So we opted to start from scratch.

Azeez


On Tue, Jan 21, 2014 at 10:07 AM, Nirmal Fernando  wrote:

> Hi Shankar,
>
> While we were moving Stratos to Apache, Apache infra guys suggested some
> tools to get SVN commit history to Git [1].
>
> [1]
> http://infrastructure.fedoraproject.org/infra/docs/hosted_git_to_svn.txt
>
>
> On Tue, Jan 21, 2014 at 2:05 AM, Selvaratnam Uthaiyashankar <
> shan...@wso2.com> wrote:
>
>> One issue is, we will loose commit information (svn blame) when we move
>> to github. Any way to import the code with those information?
>>
>> Regards,
>> Shankar
>>
>>
>> On Mon, Jan 20, 2014 at 10:59 AM, Eranda Sooriyabandara 
>> wrote:
>>
>>> Hi All,
>>> As a PoC I just completed the carbon-component-governance. Please find
>>> it in [1] and let me know your comments and suggestions. Please keep in
>>> mind that this is not in a buildable state since other components need to
>>> build before this.
>>>
>>> thanks
>>> Eranda
>>>
>>> [1] https://github.com/wso2/carbon-component-governance
>>>
>>>
>>> On Fri, Jan 17, 2014 at 9:26 PM, Afkham Azeez  wrote:
>>>
>>>>  [Sorry for the very long mail. I want to document all that I had in
>>>> mind & the stuff we discussed. I would recommend all devs to take some time
>>>> to read this]
>>>>
>>>>
>>>> I would like to summarize he discussion we had a couple of days back.
>>>>
>>>> *The Problems*
>>>> The problems we are trying to solve are as follows:
>>>>
>>>> 1. Trunk & branches structures being completely different
>>>> 2. Branches containing directories with version numbers
>>>> 3. It is impossible to move to GitHub with the current structure
>>>> because of #2
>>>> 4. It is very easy to break the build by changing already released
>>>> code. The room for human error is high.
>>>> 5. Bamboo builds are eternally broken because the build fails at some
>>>> point & Bamboo cannot continue any further
>>>> 6. When we branch, the trunk quickly becomes obsolete, and remains in
>>>> that broken state until the next major platform release.
>>>> 7. Everybody has to build all components/features, even if those are
>>>> not related to their products
>>>> 8. Fixed versions in branches instead of using SNAPSHOT versions. This
>>>> makes it impossible to upload build artifacts to Maven/Nexus repos. This
>>>> leads to #7.
>>>> 9. Impossible to integrate code quality tools such as EraInsight
>>>> because of #5
>>>>
>>>> *Proposed solution*
>>>> We have come up with the following solution after much deliberation &
>>>> thought.
>>>>
>>>> Rationale:
>>>> We started looking at other open source projects out there. We took
>>>> Axis2 as an example. Axis2 had many dependencies including Axiom,
>>>> XmlSchema, Woden, WSS4J etc. Those 3rd party dependencies were also
>>>> developed by some Axis2 contributors, but we never branched all of those
>>>> together and brought them into the same code branch. We used to start what
>>>> we used to call a release train, where the upstream code would have to be
>>>> released first before the downstream code such as Axis2 & Synapse could be
>>>> released. This way, we never had any of the problems outlined above.
>>>>
>>>> If you look at the WSO2 product releases, again, the scenario is not
>>>> that much different from the Axis2/Synapse releases. Components & features
>>>> are simply dependencies of the products. In order to get product releases
>>>> out, we first need releases of those dependencies (components/features). So
>>>> the proposal is to identify the top level components/features, and first
>>>> release that code before doing product releases. Each of those components
>>>> will have a GitHub repo. All active development will be done on the main
>>>> branch of those components, and will be branched when they are close to the
>>>> release. Instead of granting commit rights to all, we could only allow the
>>>> primary developers of those components to commit, and others can send pull
>>>> requests, which will be merged in by the primary owners after

Re: [Architecture] [Dev] Proposed code repository restructuring & move to GitHub

[Afkham Azeez]

On Wed, Jan 22, 2014 at 7:28 AM, Eranda Sooriyabandara wrote:

> Hi all,
>
>
> On Tuesday, January 21, 2014, Senaka Fernando  wrote:
>
>> Hi all,
>>
>> +1 for Sagara's proposal. These projects have a life outside the Carbon
>> Platform. But, we need to find a place to host them. If everything ends up
>> on GitHub should these be in their too? If so, are they a WSO2 repository?
>> Or is it a separate TLP?
>>
>
> Here Sagara, Senaka came up with a good point. We don't need each and
> every one to have a git repo in wso2 space but we can still use svn for
> managing these codes where not much of the developers of carbon worry
> about. WDYT?


Let's bring these dependencies into GitHub or any other repo as & when
needed. The changes we make to such dependencies need to be minimized.


>
> Thanks
> Eranda
>
>
>> Thanks,
>> Senaka.
>>
>>
>> On Tue, Jan 21, 2014 at 9:11 PM, Sagara Gunathunga wrote:
>>
>>
>>
>>
>> On Tue, Jan 21, 2014 at 3:34 PM, Sriskandarajah Suhothayan > > wrote:
>>
>> How about WSO2 Commons projects, E.g Siddhi ?
>>
>> Currently its in commons and under dependencies/commons
>>
>> Where should we have this?
>>
>> I believe projects like Siddhi also need to be top level repos may be
>> "commons-siddhi" and it don't need be in dependencies/commons anymore.
>>
>> WDYT?
>>
>>
>> Ideally these projects should be treated as external dependencies to
>> Carbon code base just like Apache XMLSchema or Axiom only difference here
>> is those project are managed by WSO2. We should create separate repos for
>> each of them and Carbon should only take them as Maven dependencies only.
>> For naming I guess "Siddhi" is a good name because "commons" part does not
>> make any meaning here.
>>
>> in my POV these should be the project we need to move out of Carbon code
>> base.
>>
>>
>> Jaggery ( we just need to get rid of SVN externals as code base it
>> already on GitHub)
>> Caramel
>> Charon
>> Balana
>> Siddhi
>>
>> Thanks !
>>
>>
>>
>>
>>
>> Suho
>>
>>
>> On Tue, Jan 21, 2014 at 3:13 PM, Eranda Sooriyabandara 
>> wrote:
>>
>> Hi All
>> Please find the updated governance component in [1].
>>
>> thanks
>> Eranda
>>
>> [1]. https://github.com/wso2/carbon-governance
>>
>>
>> On Tue, Jan 21, 2014 at 2:56 PM, Shariq Muhammed  wrote:
>>
>> On Tue, Jan 21, 2014 at 2:42 PM, Eranda Sooriyabandara 
>> wrote:
>>
>> Hi Shariq,
>> Yeah, we may not needed those to be build again and again. So let's add
>> related stubs to service-stubs directory in each repo.
>>
>>
>> Yea lets structure it that way.
>>
>>
>>
>> thanks
>> Eranda
>>
>>
>> On Tue, Jan 21, 2014 at 12:51 PM, Shariq Muhammed wrote:
>>
>> On Tue, Jan 21, 2014 at 12:38 PM, Kishanthan Thangarajah
>>
>>
>>
>> *[image: http://wso2.com] <http://wso2.com> Senaka Fernando*
>> Senior Technical Lead; WSO2 Inc.; http://wso2.com
>>
>>
>>
>> * Member; Apache Software Foundation; http://apache.org
>> <http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P: +1
>> 408 754 7388 <%2B1%20408%20754%207388>; ext: 51736*;
>>
>>
>> *M: +94 77 322 1818 <%2B94%2077%20322%201818> Linked-In:
>> http://linkedin.com/in/senakafernando
>> <http://linkedin.com/in/senakafernando>*Lean . Enterprise . Middleware
>>
>
>
> --
>
> *Eranda Sooriyabandara*Senior Software Engineer;
> Integration Technologies Team;
> WSO2 Inc.; http://wso2.com
> Lean . Enterprise . Middleware
>
> E-mail: eranda AT wso2.com
> Mobile: +94 716 472 816
> Linked-In: http://www.linkedin.com/in/erandasooriyabandara
> Blog: http://emsooriyabandara.blogspot.com/
>
>
>
>
>
>
> ___
> Dev mailing list
> d...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919 blog: **http://blog.afkham.org*<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
* linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Persisting runtime throttle data

[Afkham Azeez]

zlecast do the replication.
>>>>>>>>>
>>>>>>>>> I took into consideration the need to persist periodically instead
>>>>>>>>> of at each and every request (by spawning a separate thread that has 
>>>>>>>>> access
>>>>>>>>> to the callerContext map)...  so yes... we should think in the same 
>>>>>>>>> way for
>>>>>>>>> replicating the counters across the cluster as well.
>>>>>>>>>
>>>>>>>>> Instead of using a global counter, can we perhaps use the last
>>>>>>>>> updated timestamp of each CallerContext?  It's actually not a single
>>>>>>>>> counter we need to deal with, and each CallerContext instance will 
>>>>>>>>> have
>>>>>>>>> separate counters mapped to their throttling policy AFAIK.  
>>>>>>>>> Therefore, I
>>>>>>>>> think its probably better to update CallerContext instances based on 
>>>>>>>>> the
>>>>>>>>> last update timestamp.
>>>>>>>>>
>>>>>>>>> WDYT?
>>>>>>>>>
>>>>>>>>> If agree, then I need to figure out how to make delayed
>>>>>>>>> replication on hazlecast (is it through
>>>>>>>>> the hazelcast.heartbeat.interval.seconds config item?)
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Manoj
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Dec 17, 2013 at 4:22 PM, Srinath Perera 
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> We need to think it a cluster setup do we need persistence as
>>>>>>>>> well? As we can have replication using Hazelcast?
>>>>>>>>>
>>>>>>>>> If we need persistence, I think it is a good if a single node
>>>>>>>>> persists the current throttling values, and if that node fails, 
>>>>>>>>> someone
>>>>>>>>> else takes it place?
>>>>>>>>>
>>>>>>>>> Current implementation sync the values across the cluster per each
>>>>>>>>> message, which introduce significant overhead. I think we should go 
>>>>>>>>> to a
>>>>>>>>> model where each node collects and update the values once few seconds.
>>>>>>>>>
>>>>>>>>> idea is
>>>>>>>>> 1) there is a global counter, that we use to throttle
>>>>>>>>> 2) Each node keep a global counter, and periodically it update the
>>>>>>>>> global counter using value in location counter and reset the counter 
>>>>>>>>> and
>>>>>>>>> read the current global counter.
>>>>>>>>> 3) Until next update, each node make decisions based on local
>>>>>>>>> global counter values it has read already
>>>>>>>>>
>>>>>>>>> This will mean that the throttling will throttle close to the
>>>>>>>>> limit, not exactly at the limit. However, IMHO, that is not a problem 
>>>>>>>>> for
>>>>>>>>> throttling usecase.
>>>>>>>>>
>>>>>>>>> --Srinath
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Dec 16, 2013 at 7:20 PM, Manoj Fernando wrot
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Manoj Fernando
>>>>>>>> Director - Solutions Architecture
>>>>>>>>
>>>>>>>> Contact:
>>>>>>>> LK -  +94 112 145345
>>>>>>>> Mob: +94 773 759340
>>>>>>>> www.wso2.com
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Manoj Fernando
>>>>>>> Director - Solutions Architecture
>>>>>>>
>>>>>>> Contact:
>>>>>>> LK -  +94 112 145345
>>>>>>> Mob: +94 773 759340
>>>>>>> www.wso2.com
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 
>>>>>> Srinath Perera, Ph.D.
>>>>>>http://people.apache.org/~hemapani/
>>>>>>http://srinathsview.blogspot.com/
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Manoj Fernando
>>>>> Director - Solutions Architecture
>>>>>
>>>>> Contact:
>>>>> LK -  +94 112 145345
>>>>> Mob: +94 773 759340
>>>>> www.wso2.com
>>>>>
>>>>> ___
>>>>> Architecture mailing list
>>>>> Architecture@wso2.org
>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> *S. Suhothayan *
>>>> Associate Technical Lead,
>>>>  *WSO2 Inc. *http://wso2.com
>>>> * <http://wso2.com/>*
>>>> lean . enterprise . middleware
>>>>
>>>>
>>>> *cell: (+94) 779 756 757 <%28%2B94%29%20779%20756%20757> | blog:
>>>> http://suhothayan.blogspot.com/ <http://suhothayan.blogspot.com/> twitter:
>>>> http://twitter.com/suhothayan <http://twitter.com/suhothayan> | linked-in:
>>>> http://lk.linkedin.com/in/suhothayan 
>>>> <http://lk.linkedin.com/in/suhothayan>*
>>>>
>>>>
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> Manoj Fernando
>>> Director - Solutions Architecture
>>>
>>> Contact:
>>> LK -  +94 112 145345
>>> Mob: +94 773 759340
>>> www.wso2.com
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>>
>> *S. Suhothayan*
>> Associate Technical Lead,
>>  *WSO2 Inc. *http://wso2.com
>> * <http://wso2.com/>*
>> lean . enterprise . middleware
>>
>>
>> *cell: (+94) 779 756 757 <%28%2B94%29%20779%20756%20757> | blog:
>> http://suhothayan.blogspot.com/ <http://suhothayan.blogspot.com/> twitter:
>> http://twitter.com/suhothayan <http://twitter.com/suhothayan> | linked-in:
>> http://lk.linkedin.com/in/suhothayan <http://lk.linkedin.com/in/suhothayan>*
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Manoj Fernando
> Director - Solutions Architecture
>
> Contact:
> LK -  +94 112 145345
> Mob: +94 773 759340
> www.wso2.com
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919 blog: **http://blog.afkham.org*<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
* linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Persisting runtime throttle data

[Afkham Azeez]

Currently, throttling configuration is based on WS-Policy. It would be good
if the new implementation uses a proper rule language.


On Sat, Jan 25, 2014 at 6:59 PM, Afkham Azeez  wrote:

> Given how long it has already taken to understand this legacy code, it
> will be much easier to come up with a very simple design, focusing on the
> problem we are trying to solve, and write it from scratch. To be frank, I
> think it can be done in a week if you fully focus on it. My suggestion was
> to write a throttling decision making engine, and provide nice APIs to the
> outside world. We discussed in detail what the problem at hand is, and it
> is possible to come up with an elegant design & implement this from scratch.
>
> Azeez
>
>
> On Sat, Jan 25, 2014 at 11:53 AM, Manoj Fernando  wrote:
>
>> During a discussion with Srinath and Azeez yesterday, the preference was
>> to rewrite the throttle core with persistence and Hazelcast based
>> replication in mind.  I am progressing in that direction and will be
>> reviewing with Srinath periodically.
>>
>> Regards,
>> Manoj
>>
>>
>> On Mon, Jan 13, 2014 at 2:52 PM, Sriskandarajah Suhothayan > > wrote:
>>
>>> Siddhi support having Execution Plans, which can be mapped to one of the
>>> current policies. I believe this will reduce the complexity of
>>> the throttling execution logic.
>>>
>>> Suho
>>>
>>>
>>> On Mon, Jan 13, 2014 at 1:34 PM, Manoj Fernando  wrote:
>>>
>>>> Yes, this is something important to consider when we re-write the
>>>> throttle core eventually.  However, the persistence logic we want to bring
>>>> in will not have any tight coupling with the throttle core.  As per the
>>>> design we have finalized now, the throttle persistence module will retrieve
>>>> the counters from the Axis2 context, and as long as the context is updated
>>>> by the core (irrespective of the implementation), the persistence core will
>>>> be re-usable.
>>>>
>>>> One thing we should consider is the backward compatibility with current
>>>> throttle policy definitions IF we decide to bring in Siddhi into the
>>>> picture.  In the case of API Manager for example, I think users are more
>>>> used to managing policies the way it is done now (i.e. tier.xml), so IMO we
>>>> should continue to support that.  Is there such thing as a policy
>>>> definition plugin for Siddhi btw (may be not... right?) ?
>>>>
>>>> Regards,
>>>> Manoj
>>>>
>>>>
>>>> On Fri, Jan 3, 2014 at 4:55 PM, Sriskandarajah Suhothayan <
>>>> s...@wso2.com> wrote:
>>>>
>>>>> Is there any possibility of using Distributed CEP/Siddhi here? Because
>>>>> with Siddhi we can have some flexibility in the way we want to throttle
>>>>> and throttling is a common usecase of CEP. Its underline architecture
>>>>> also uses Hazelcast or Storm for distributed processing.
>>>>>
>>>>> Regards
>>>>> Suho
>>>>>
>>>>>
>>>>> On Tue, Dec 24, 2013 at 8:54 AM, Manoj Fernando wrote:
>>>>>
>>>>>> +1.  Changing caller contexts in to a Hazlecast map would require
>>>>>> some significant changes to the throttle core, which may eventually be
>>>>>> re-written.
>>>>>>
>>>>>> Will update the design.
>>>>>>
>>>>>> Thanks,
>>>>>> Manoj
>>>>>>
>>>>>>
>>>>>> On Mon, Dec 23, 2013 at 4:09 PM, Srinath Perera wrote:
>>>>>>
>>>>>>> Manoj, above plan look good.
>>>>>>>
>>>>>>> I chatted with Azeez, and we cannot register a Entry listener as I
>>>>>>> mentioned before because hazecast does not support entry listeners for
>>>>>>> atomic long.
>>>>>>>
>>>>>>> --Srinath
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Dec 23, 2013 at 11:15 AM, Manoj Fernando wrote:
>>>>>>>
>>>>>>>> Short update after the discussion with Azeez.
>>>>>>>>
>>>>>>>> - The need to re-write the throttle core is still at large, so the
>>>>>>>> best was to see how we can decouple the persistence logic from the 
>>>>>>>> thro

Re: [Architecture] Fwd: How can we patch Jaggery Apps?

[Afkham Azeez]

I don't think that we should support patching jaggery apps, webapps, or any
other app for that matter. As a matter of fact, there is no such thing as
patching a .war file or a PHP app. If there is some problem in an app, the
solution is to either overwrite it, or introduce a new version.

Azeez


On Sat, Jan 25, 2014 at 4:53 PM, Sameera Medagammaddegedara <
samee...@wso2.com> wrote:

> Hello Everyone,
>
> *Problem*
>
>- As it stands ,if a Jaggery application needs to be updated the user
>must manually copy the required files
>- This introduces a number of problems
>   - If several files need to be changed it will become a chore
>   - A user may forget to copy one or more files
>   - It departs from the normal way in which patches are applied to
>   other WSO2 products
>- The files that could be included in a patch to a Jaggery file could
>include (but is not limited ) to the following;
>   1. JAG files
>   2. JS files
>   3. Jaggery Modules ( These will be JS files)
>   4. Images and CSS files
>   5. JSON files
>
> *Suggestion*
>
>- Package the files to be replaced in a zip format
>- All Jaggery App patches could be placed in the
>repository/components/patches/jaggeryapps similar to the way existing
>patches are applied
>- *Structure of the patch*
>- Please refer to attached image
>   - The files to be updated would need to be organized according to
>   structure of the app or module to be patched
>   - Before the application is deployed the archive is extracted and
>the files copied over to the mirrored location in the app or module to be
>patched
>
> *Open Questions*
>
>- How do we handle reverting a patch?
>- How can we apply the patch before Jaggery app is deployed?
>
> Thank You,
>
> Sameera
>
>
> --
> Sameera Medagammaddegedara
> Software Engineer
>
> Contact:
> Email: samee...@wso2.com
> Mobile: + 94 077 255 3005
>
> _______
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919 blog: **http://blog.afkham.org*<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
* linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Fwd: How can we patch Jaggery Apps?

[Afkham Azeez]

So it can follow the process of normal
>>> artifact update.
>>>
>>> But the main point here on why do we need to patch jaggery apps is that,
>>> with some product releases, we are also releasing jaggery apps as part of
>>> it. So we need a way to patch those released apps.
>>>
>>>
>>>>
>>>>- The files that could be included in a patch to a Jaggery file
>>>>could include (but is not limited ) to the following;
>>>>   1. JAG files
>>>>   2. JS files
>>>>   3. Jaggery Modules ( These will be JS files)
>>>>   4. Images and CSS files
>>>>   5. JSON files
>>>>
>>>> *Suggestion*
>>>>
>>>>- Package the files to be replaced in a zip format
>>>>- All Jaggery App patches could be placed in the
>>>>repository/components/patches/jaggeryapps similar to the way existing
>>>>patches are applied
>>>>- *Structure of the patch*
>>>>- Please refer to attached image
>>>>   - The files to be updated would need to be organized according
>>>>   to structure of the app or module to be patched
>>>>   - Before the application is deployed the archive is extracted
>>>>and the files copied over to the mirrored location in the app or module 
>>>> to
>>>>be patched
>>>>
>>>>
>>> The important question to ask is who will handle the patch applying
>>> process for jaggery apps?
>>>
>>>  *Open Questions*
>>>>
>>>>- How do we handle reverting a patch?
>>>>- How can we apply the patch before Jaggery app is deployed?
>>>>
>>>> Thank You,
>>>>
>>>> Sameera
>>>>
>>>>
>>>> --
>>>> Sameera Medagammaddegedara
>>>> Software Engineer
>>>>
>>>> Contact:
>>>> Email: samee...@wso2.com
>>>> Mobile: + 94 077 255 3005
>>>>
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> *Kishanthan Thangarajah*
>>> Senior Software Engineer,
>>> Platform Technologies Team,
>>> WSO2, Inc.
>>> lean.enterprise.middleware
>>>
>>> Mobile - +94773426635
>>> Blog - *http://kishanthan.wordpress.com
>>> <http://kishanthan.wordpress.com>*
>>> Twitter - *http://twitter.com/kishanthan
>>> <http://twitter.com/kishanthan>*
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>>
>>
>> *[image: http://wso2.com] <http://wso2.com> Senaka Fernando*
>> Senior Technical Lead; WSO2 Inc.; http://wso2.com
>>
>>
>>
>> * Member; Apache Software Foundation; http://apache.org
>> <http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P: +1
>> 408 754 7388 <%2B1%20408%20754%207388>; ext: 51736*;
>>
>>
>> *M: +94 77 322 1818 <%2B94%2077%20322%201818> Linked-In:
>> http://linkedin.com/in/senakafernando
>> <http://linkedin.com/in/senakafernando>*Lean . Enterprise . Middleware
>>
>
>
>
> --
> *Kishanthan Thangarajah*
> Senior Software Engineer,
> Platform Technologies Team,
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile - +94773426635
> Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>*
> Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>*
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919 blog: **http://blog.afkham.org*<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
* linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Persisting runtime throttle data

[Afkham Azeez]

I don't think we need a single node caller context. This is a feature that
will always get used in production in a cluster.
On Jan 28, 2014 7:40 AM, "Manoj Fernando"  wrote:

> Thought of some improvements.
>
> - We shall have an AbstractThrottleDecisionEngine so that we can extend
> the core to support various decision engines later on (to accommodate
> suggestions from Suho and Senaka).
> - Make CallerContext abstract so extend into ClusterAwareCallerContext and
> SingleNodeCallerContext.
>
> Regards,
> Manoj
>
>
> On Mon, Jan 27, 2014 at 5:33 PM, Manoj Fernando  wrote:
>
>> Initial code checked in @ http://svn.wso2.org/repos/wso2/people/manojf .
>>
>> Next : implementing periodic counter replication,  persistence.
>>
>> - Manoj
>>
>>
>> On Mon, Jan 27, 2014 at 9:16 AM, Srinath Perera  wrote:
>>
>>> Hi Suho,
>>>
>>> I think we need throttling to work without having to run a distributed
>>> CEP. Using Siddhi is fine, as that is transparent, but need for Strom to
>>> run thottling usecae is too much IMO.
>>>
>>> --Srinath
>>>
>>>
>>> On Fri, Jan 3, 2014 at 4:55 PM, Sriskandarajah Suhothayan >> > wrote:
>>>
 Is there any possibility of using Distributed CEP/Siddhi here? Because
 with Siddhi we can have some flexibility in the way we want to throttle
 and throttling is a common usecase of CEP. Its underline architecture
 also uses Hazelcast or Storm for distributed processing.

 Regards
 Suho


 On Tue, Dec 24, 2013 at 8:54 AM, Manoj Fernando wrote:

> +1.  Changing caller contexts in to a Hazlecast map would require some
> significant changes to the throttle core, which may eventually be
> re-written.
>
> Will update the design.
>
> Thanks,
> Manoj
>
>
> On Mon, Dec 23, 2013 at 4:09 PM, Srinath Perera wrote:
>
>> Manoj, above plan look good.
>>
>> I chatted with Azeez, and we cannot register a Entry listener as I
>> mentioned before because hazecast does not support entry listeners for
>> atomic long.
>>
>> --Srinath
>>
>>
>> On Mon, Dec 23, 2013 at 11:15 AM, Manoj Fernando wrote:
>>
>>> Short update after the discussion with Azeez.
>>>
>>> - The need to re-write the throttle core is still at large, so the
>>> best was to see how we can decouple the persistence logic from the 
>>> throttle
>>> core (at least as much as possible).
>>> - A cluster updatable global counter will be included to the
>>> ThrottleContext.  The idea is that each node will periodically broadcast
>>> the local counter info to the members in the cluster and the
>>> ThrottleConfiguration will update the value of the Global counter 
>>> summing
>>> up the local counter values.
>>> - The ThrottleConfiguration will also push the global counter values
>>> to the Axis2 Configuration Context; a K, V pairs identified by the
>>> ThrottleContext ID.
>>> - A new platform component needs to be written to read the throttle
>>> related Axis2 Config Context list and persist them periodically 
>>> (duration
>>> configurable).  The throttle core will have no visibility into this
>>> persistence logic, so this will be completely decoupled.
>>> - So who should do the persistence?  We can start with letting all
>>> nodes to persist first, but later (or in parallel) we can improve the
>>> Hazlecast's leader election (if that's not already there), so that the
>>> leader takes the responsibility of persisting.
>>> - The counters will be read off the persistence store at the time of
>>> Hazlecast Leader election takes place? (An alternative is to load the
>>> global counters at the init of ThrottleConfiguration but that means
>>> coupling throttle core with persistence.)
>>>
>>> I will update the design accordingly.
>>>
>>> Any more thoughts or suggestions?
>>>
>>> Regards,
>>> Manoj
>>>
>>>
>>> On Thu, Dec 19, 2013 at 12:30 PM, Manoj Fernando wrote:
>>>
 +1. Let me setup a time.

 Regards,
 Manoj


 On Thursday, December 19, 2013, Srinath Perera wrote:

> We need Azeez's feedback. Shall you, myself, and Azeez chat
> sometime and decide on the first Arch design?
>
>
> On Thu, Dec 19, 2013 at 11:55 AM, Manoj Fernando 
> wrote:
>
> Hi Srinath,
>
> That sounds like a much cleaner solution.  We can perhaps use the
> native map-store declarative [1] which I think does something 
> similar.  It
> may sound a little silly to ask... but are we keeping Hazlecast 
> active on a
> single node environment as well? :) Otherwise we will have to handle
> persistence on a single node in a different way.   This is with the
> assumption of needing to persist throttle data on a single node 

Re: [Architecture] Fwd: How can we patch Jaggery Apps?

[Afkham Azeez]

On Tue, Jan 28, 2014 at 11:55 AM, Sanjeewa Malalgoda wrote:

>
>
>
> On Tue, Jan 28, 2014 at 11:37 AM, Ramith Jayasinghe wrote:
>
>> Hi Kishanthan,
>>   if we version the webapp(s) will that change the endpoint? if so the
>> reality of that is users has to keep changing configuration(s) (else where)
>> which may refer to these endpoints (think about complex deployment patterns
>> which users will do). That would introduce more complexities and more
>> headaches supporting released products.
>>
> Yes, if we take auth application as an example, application creators will
> embed auth application url in client application and distribute it. So if
> we change application url(by adding version) in the middle, then it will
> effect to all client applications installed on mobile devices and etc.
>
>
We are not the first ones to face this problem. Tomcat already has a
solution for that based on the context.xml file where your webapp name file
name & context can be different.
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Fwd: How can we patch Jaggery Apps?

[Afkham Azeez]

The bottom line is, there are tried & tested solutions for these problems
that have worked over the past many years. We don't have to reinvent
solutions only to figure out a few years later that the tried & tested
solution is in fact the best one. The branching strategy is a good example
where we followed the unconventional version within the branch strategy
rather than the entire branch having a single version which is what
everybody was/is doing. Now we are rectifying that mistake. Similarly, the
tried & tested solution for webapps is not to patch parts of it, but to
release a new version, or modify the existing version deploy. We don't have
to invent a patching strategy for webapps.
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Fwd: How can we patch Jaggery Apps?

[Afkham Azeez]

Cluster-wide patch distribution will be handle by the Operations Center.

Azeez


On Tue, Jan 28, 2014 at 12:40 PM, Ruchira Wageesha  wrote:

>
>>>
>>> If we patch a webapp, then we will do it only on master node and the
>>> patching process is for that. Synchronizing workers with master is a
>>> different task which belongs to depsync. Why do we need to mix up the
>>> things? May be I am missing something?
>>>
>>
>> No, you can't have patching only at master node and let dep-synch to take
>> care the rest of the patching. This will leave the system in a stage where
>> the slave nodes depends on dep-sych for the patching to work. If we
>> introduce patching process, it should be consistence across all the nodes
>> (servers). This is how we patch OSGi bundles.
>>
>>>
>>>>>>>>>>>>>>  This might be a different conversation, but just to share
> my idea
>
> Why dep-synch doesn't sync the patches is because the way we have limited
> our own depsync model. i.e. We have used depsync only for synching so
> called artifacts.
>
> But assume, if we had a kernal with just an update manager like the ubuntu
> kernal. When we want to push something, we send an update notification and
> then server will update itself followed by a restart if it needed. When we
> want to do something to a cluster, what we do is just sending the message
> describing what we want to do. i.e. fetching *.jars, executing those
> jars(in case of a local db migration etc.) and restarting the server,
> deleting unwanted stuff etc. Even, we can remotely convert the whole ESB
> cluster to a different cluster.
>
> This would be a dumb idea, but that's how I see it personally.
>
> /Ruchira
>
> --
>
> *Ruchira Wageesha **Associate Technical Lead*
> *WSO2 Inc. - lean . enterprise . middleware |  wso2.com <http://wso2.com>*
>
> *email: ruch...@wso2.com ,   blog:
> ruchirawageesha.blogspot.com <http://ruchirawageesha.blogspot.com>,
> mobile: +94 77 5493444 <%2B94%2077%205493444>*
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919 blog: **http://blog.afkham.org*<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
* linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Improving BAM toolbox deployment

[Afkham Azeez]

Can you schedule a short meeting for us to properly understand the problem
at hand? I think that would be more effective. We may need some
whiteboarding.

Azeez


On Mon, Jan 27, 2014 at 7:00 PM, Maninda Edirisooriya wrote:

> Hi all,
>
> At present our BAM toolbox deployment works fine when the instructions are
> followed to the point. But they have some problems.
>
> 1. Hive script name has a generated random number appended which is not
> user friendly
> 2. When toolboxes are required to be dep-synched, toolbox deployment
> features have to be uninstaled from the other BAM nodes.
> 3. and some other problems.
>
> In order to fix these issues we have decided to do the following.
>
> 1. Every artifact deployed from the toolbox should be editable from the UI.
>
> i) Streams will be edited from the new UI that is going to be implemented.
> ii) Hive scripts can already be edited from the UI
> iii) Dashboards will be editable with the UES jaggery editor.
>
> 2. Every BAM node should include the BAM toolbox deployer feature and
> every change done on each artifact should be correctly dep-synched to all
> other nodes.
>
> i.e. When a dashboard is edited, a hive script is edited, stream is
> created all should be propagated to  other nodes.
>
>
> But there is a critical problem we are facing against achieving the
> requirements.
> When toolbox is deployed 3 things happen.
>
> 1. Create stream definitions
> 2. Deploy and schedule hive scripts
> 3. Deploy dashboard files
>
> The problem happens as when we edit some of these artifacts, they are not
> propagated back to .tbox archive file. As archive file is deployed again at
> the startup of the server, we should maintain the status of the toolbox
> (whether it has already installed) locally or in the shared registry in
> order to avoid redeploying the .tbox file again which will discard the
> changes made on the artifacts. (i.e. changed hive scripts and jag files
> will be replaced with original files if overwritten.)
>
> We have considered many possible solutions to overcome this issue but
> could not come to an flawless solution.
>
> Are we trying to solve the right problem? Or is this a well known problem
> when dep-syncing artifacts from an archive? What are the possible solutions?
>
> Anjana / Sinthuja please add, if I have missed some important points.
>
> *Maninda Edirisooriya*
> Software Engineer
>
> *WSO2, Inc. *lean.enterprise.middleware.
>
> *Blog* : http://maninda.blogspot.com/
> *Phone* : +94 777603226
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919 blog: **http://blog.afkham.org*<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
* linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Fwd: How can we patch Jaggery Apps?

[Afkham Azeez]

On Wed, Jan 29, 2014 at 12:18 AM, Manuranga Perera  wrote:

> The solution is to update the app through patch file if the app is uses a
>> textual scripting language
>>
> this is a nice solution, but we need support form carbon kernel to do
> this, so we don' have to ask users to go and do it manually.
>

You can't expect a solution from Carbon kernel for this because patching
deployed applications cannot be done in a generic manner.


>
> --
> With regards,
> *Manu*ranga Perera.
>
> phone : 071 7 70 20 50
> mail : m...@wso2.com
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>*
*email: **az...@wso2.com* 
* cell: +94 77 3320919 blog: **http://blog.afkham.org*<http://blog.afkham.org>
*twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
* linked-in: **http://lk.linkedin.com/in/afkhamazeez
<http://lk.linkedin.com/in/afkhamazeez>*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture