Re: [Architecture] Carbon C5 - Server Configuration Model

[Ishara Cooray]

Thanks Danesh.

Do we have a time line for next carbon-datasources release?

Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Mon, May 29, 2017 at 7:11 PM, Danesh Kuruppu  wrote:

> Hi Ishara,
>
> What is the conclusion for supporting database configurations in C5
>> configuration model?
>>
>
> We decided to maintain datasource related configuration in
> deployment.yaml. There is no default values for datasource configuration.
> If any product needs to add datasources, those configurations should
> mention in the deployment.yaml.
>
>
>> In which kernel version we can expect this ?
>>
>
> This is in a separate repository(carbon-datasources)[1]. We are going to
> add this configuration model in next carbon-datasources release.
>
> 1. https://github.com/wso2/carbon-datasources
>
> Thanks
> --
>
> *Danesh Kuruppu*
> Senior Software Engineer | WSO2
>
> Email: dan...@wso2.com
> Mobile: +94 (77) 1690552 <+94%2077%20169%200552>
> Web: WSO2 Inc 
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Carbon C5 - Server Configuration Model

[Danesh Kuruppu]

Hi Ishara,

What is the conclusion for supporting database configurations in C5
> configuration model?
>

We decided to maintain datasource related configuration in deployment.yaml.
There is no default values for datasource configuration. If any product
needs to add datasources, those configurations should mention in the
deployment.yaml.


> In which kernel version we can expect this ?
>

This is in a separate repository(carbon-datasources)[1]. We are going to
add this configuration model in next carbon-datasources release.

1. https://github.com/wso2/carbon-datasources

Thanks
-- 

*Danesh Kuruppu*
Senior Software Engineer | WSO2

Email: dan...@wso2.com
Mobile: +94 (77) 1690552 <+94%2077%20169%200552>
Web: WSO2 Inc 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Carbon C5 - Server Configuration Model

[Imesh Gunaratne]

Thanks for the clarification Danesh! In that situation, we might need to
maintain a default value configuration file per feature or component.

On Wed, Mar 8, 2017 at 10:37 AM, Danesh Kuruppu  wrote:

> Hi Imesh,
>
> Shall we use the same default.yaml to define datasources with default
>>> configuration of the product. because in carbon-datasources, we don't have
>>> default database configurations and there are coming from different
>>> components. but we read datasources configuration from carbon-datasources.
>>> So we need a place to get the default values, if it is not specified in
>>> deployment.yaml.
>>>
>>
>> ​According to the initial discussion we had, may be we can have the
>> default values in the code using annotations. Do we see any problems with
>> that?
>>
>
> The Problem here is, bean classes related to datasources are defined in
> carbon-datasources, but the component doesn't contain any default values.
> It creates databsource objects based on the config files in the datasources
> directory(in C4, it is based on master-datasources.xml, etc) and
> configuration files are created or modified at product level.
>
> e.g.: If APIM needs separate datasource, it adds related configuration to
> the datasource config files. So at runtime, carbon-datasources component
> reads configuration and creates related datasource objects.
>
> With the new config model, it is not mandatory to have those configuration
> in deployment.yaml. So we need to have a place where we can get the default
> values if it is not specified in the deployment.yaml.
>
> Thanks
> Danesh
> --
>
> *Danesh Kuruppu*
> Senior Software Engineer | WSO2
>
> Email: dan...@wso2.com
> Mobile: +94 (77) 1690552 <+94%2077%20169%200552>
> Web: WSO2 Inc 
>
>


-- 
*Imesh Gunaratne*
Software Architect
WSO2 Inc: http://wso2.com
T: +94 11 214 5345 M: +94 77 374 2057
W: https://medium.com/@imesh TW: @imesh
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

[Danesh Kuruppu]

Hi Imesh,

Shall we use the same default.yaml to define datasources with default
>> configuration of the product. because in carbon-datasources, we don't have
>> default database configurations and there are coming from different
>> components. but we read datasources configuration from carbon-datasources.
>> So we need a place to get the default values, if it is not specified in
>> deployment.yaml.
>>
>
> ​According to the initial discussion we had, may be we can have the
> default values in the code using annotations. Do we see any problems with
> that?
>

The Problem here is, bean classes related to datasources are defined in
carbon-datasources, but the component doesn't contain any default values.
It creates databsource objects based on the config files in the datasources
directory(in C4, it is based on master-datasources.xml, etc) and
configuration files are created or modified at product level.

e.g.: If APIM needs separate datasource, it adds related configuration to
the datasource config files. So at runtime, carbon-datasources component
reads configuration and creates related datasource objects.

With the new config model, it is not mandatory to have those configuration
in deployment.yaml. So we need to have a place where we can get the default
values if it is not specified in the deployment.yaml.

Thanks
Danesh
-- 

*Danesh Kuruppu*
Senior Software Engineer | WSO2

Email: dan...@wso2.com
Mobile: +94 (77) 1690552
Web: WSO2 Inc 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Carbon C5 - Server Configuration Model

[Imesh Gunaratne]

On Tue, Mar 7, 2017 at 11:09 PM, Danesh Kuruppu  wrote:

> Hi all,
>
> Shall we use the same default.yaml to define datasources with default
> configuration of the product. because in carbon-datasources, we don't have
> default database configurations and there are coming from different
> components. but we read datasources configuration from carbon-datasources.
> So we need a place to get the default values, if it is not specified in
> deployment.yaml.
>

​According to the initial discussion we had, may be we can have the default
values in the code using annotations. Do we see any problems with that?

Thanks
Imesh


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

Re: [Architecture] Carbon C5 - Server Configuration Model

[Danesh Kuruppu]

Hi all,

Shall we use the same default.yaml to define datasources with default
configuration of the product. because in carbon-datasources, we don't have
default database configurations and there are coming from different
components. but we read datasources configuration from carbon-datasources.
So we need a place to get the default values, if it is not specified in
deployment.yaml.

Thanks
Danesh

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

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

Re: [Architecture] Carbon C5 - Server Configuration Model

[Thusitha Thilina Dayaratne]

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

Re: [Architecture] Carbon C5 - Server Configuration Model

[Sagara Gunathunga]

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 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 
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>

>>>
>>>
>>> --
>>>
>>> *Danesh Kuruppu*
>>> Senior Software Engineer | WSO2

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 


 ___
 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 
>>
>>
>
>
> --
> 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/
* *
*email: **az...@wso2.com* 
* cell: +94 77 3320919blog: **http://blog.afkham.org*

*twitter: **http://twitter.com/afkham_azeez*

*linked-in: **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

[Ruwan Abeykoon]

Hi All,
What if we can bundle another level of "default-deployment.yaml" which is
packed inside a jar. This will provide the defaults for the product X. This
file is/meant not user editable as it is inside a jar. Product team can
select the values for "default-deployment.yaml" based on their requirements.

So any property overridden like,

Component Class default -> "default-deployment.yaml" -> "deployment.yaml"

Cheers,
Ruwan

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 


 ___
 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 
>>
>>
>
>
> --
> 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
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 

*Ruwan Abeykoon*
*Associate Director/Architect**,*
*WSO2, Inc. http://wso2.com  *
*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

[Sagara Gunathunga]

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


-- 
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
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Carbon C5 - Server Configuration Model

[Danesh Kuruppu]

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.

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 
>>
>>
>> ___
>> 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
Web: WSO2 Inc 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Carbon C5 - Server Configuration Model

[Jayanga Kaushalya]

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

Re: [Architecture] Carbon C5 - Server Configuration Model

[Danesh Kuruppu]

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
Web: WSO2 Inc 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Carbon C5 - Server Configuration Model

[Danesh Kuruppu]

Hi Abimaran,

Kernel going to provide the relevant config object. There will be an osgi
service to provide relevant object for the given bean class. Kernel doesn't
need to know exact bean class. We use reflection to generate the bean
class. Kernel will not dependent on any product component.

Thanks
Danesh

On Tue, Nov 29, 2016 at 10:23 PM, Abimaran Kugathasan 
wrote:

> Hi Danesh,
>
> 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.
>>
>>
> Who will generate the relevant config beans? If it's by kernel, how does
> the kernel knows a bean from a product component? Will this lead to a
> cyclic dependency like product component should depend on kernel and the
> kernel should know the the product component to find the relevant config
> bean?
>
>
>>
>>-
>>
>> 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 Kuruppu*
>> Senior Software Engineer | WSO2
>>
>> Email: dan...@wso2.com
>> Mobile: +94 (77) 1690552
>> Web: WSO2 Inc 
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Thanks
> Abimaran Kugathasan
> Senior Software Engineer - API Technologies
>
> Email : abima...@wso2.com
> Mobile : +94 773922820 <+94%2077%20392%202820>
>
> 

Re: [Architecture] Carbon C5 - Server Configuration Model

[Abimaran Kugathasan]

Hi Danesh,

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.
>
>
Who will generate the relevant config beans? If it's by kernel, how does
the kernel knows a bean from a product component? Will this lead to a
cyclic dependency like product component should depend on kernel and the
kernel should know the the product component to find the relevant config
bean?


>
>-
>
> 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 Kuruppu*
> Senior Software Engineer | WSO2
>
> Email: dan...@wso2.com
> Mobile: +94 (77) 1690552
> Web: WSO2 Inc 
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Thanks
Abimaran Kugathasan
Senior Software Engineer - API Technologies

Email : abima...@wso2.com
Mobile : +94 773922820


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

Re: [Architecture] Carbon C5 - Server Configuration Model

[Ramith Jayasinghe]

to me that makes sense. we started having the same thing since mb v 3.0.0.
it even put out a (helpful) warnings during the start up if any
configuration is missing in the config file and (default) value server
chose to go with.

On Tue, Nov 29, 2016 at 1:18 PM, Dilan Udara Ariyaratne 
wrote:

> Hi Ruwan,
>
> The purpose of suggesting to move these default values to CONSTANTS is as
> follows.
> Instead of simply setting a raw value to a bean property, by setting it up
> via a CONSTANT with a meaningful name like DEFAULT_VERSION brings
> the message that unless you set an alternative value via the yaml file, a
> default value will be set via this CONSTANT.
>
> It's true that a property like version would change from one release to
> another. But it remains as a CONSTANT for a particular release which we
> need to understand in my opinion.
>
> Thanks,
> Dilan.
>
> *Dilan U. Ariyaratne*
> Senior Software Engineer
> WSO2 Inc. 
> Mobile: +94766405580 <%2B94766405580>
> lean . enterprise . middleware
>
>
> On Tue, Nov 29, 2016 at 7:27 AM, Ruwan Abeykoon  wrote:
>
>> Hi Dilan,
>> -1 moving the default value in the properties to constants, since they
>> are not constants. Most of the values within those defaults will be changed
>> over the time, when we learn more about the system behavior, over many
>> release cycles.
>>
>> For the propose of readability and maintainability the original code
>> looks better than the suggestion.
>>
>> i.e
>> @Element(description = "server version")
>> private String version = "5.2.0";
>>
>> is better than
>> @Element(description = "server version")
>> private String version = CarbonConfigurationConstants.DEFAULT_VERSION;
>>
>> Cheers,
>> Ruwan
>>
>> On Mon, Nov 28, 2016 at 9:08 PM, Dilan Udara Ariyaratne 
>> wrote:
>>
>>> Hi Danesh,
>>>
>>> Referring to the following,
>>>
>>> @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";
>>>
>>> ...
>>>
>>> }
>>>
>>> In a developer's perspective, it would be more meaningful to define any
>>> default value as a separate CONSTANT in the code level and
>>> set any bean property similar to above with such a constant for better
>>> readability.
>>>
>>> For ex:
>>>
>>> @Configuration(namespace = "wso2.carbon", description = "Carbon 
>>> Configuration Parameters")
>>> public class CarbonConfiguration {
>>>
>>> @Element(description = "value to uniquely identify a server", required 
>>> = true)
>>> private String id = CarbonConfigurationConstants.DEFAULT_ID;
>>> @Element(description = "server name")
>>> private String name = CarbonConfigurationConstants.DEFAULT_NAME;
>>> @Element(description = "server version")
>>> private String version = CarbonConfigurationConstants.DEFAULT_VERSION;
>>> ...
>>> }
>>>
>>> In the meantime, also have the following question.
>>>
>>> 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 ?
>>>
>>> Thanks,
>>> Dilan.
>>>
>>> *Dilan U. Ariyaratne*
>>> Senior Software Engineer
>>> WSO2 Inc. 
>>> Mobile: +94766405580 <%2B94766405580>
>>> lean . enterprise . middleware
>>>
>>>
>>> On Mon, Nov 28, 2016 at 10:58 AM, Danesh Kuruppu 
>>> wrote:
>>>
 Hi Rukshan,

 No. We are going to include this in next kernel release(5.2.0).

 Thanks
 Danesh

 On Mon, Nov 28, 2016 at 10:26 AM, Rukshan Premathunga  wrote:

> Hi Danesh,
>
> Is this feature is available now? if so can you mention the kernel
> version please?
>
> Thanks and Regards
>
> On Tue, Nov 22, 2016 at 12:22 PM, Danesh Kuruppu 
> wrote:
>
>> Hi Nuwan,
>>
>> Can you also provide an example bean class for the netty listener?
>>> That would make it clear how the bean class and its nested classes 
>>> would be
>>> annotated when array elements come into play.
>>>
>>
>> Please check TransportsConfiguration sample below. We need to mention
>> the default values of an array or collection in class constructor as 
>> below.
>>
>> @Configuration(namespace = "wso2.transports.netty", description = "Netty 
>> Transport Configurations")
>> public class TransportsConfiguration {
>>
>> //default values of an array or collection need to mention in class 
>> constructor
>> public TransportsConfiguration() {
>> 

Re: [Architecture] Carbon C5 - Server Configuration Model

[Dilan Udara Ariyaratne]

Hi Ruwan,

The purpose of suggesting to move these default values to CONSTANTS is as
follows.
Instead of simply setting a raw value to a bean property, by setting it up
via a CONSTANT with a meaningful name like DEFAULT_VERSION brings
the message that unless you set an alternative value via the yaml file, a
default value will be set via this CONSTANT.

It's true that a property like version would change from one release to
another. But it remains as a CONSTANT for a particular release which we
need to understand in my opinion.

Thanks,
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Tue, Nov 29, 2016 at 7:27 AM, Ruwan Abeykoon  wrote:

> Hi Dilan,
> -1 moving the default value in the properties to constants, since they are
> not constants. Most of the values within those defaults will be changed
> over the time, when we learn more about the system behavior, over many
> release cycles.
>
> For the propose of readability and maintainability the original code looks
> better than the suggestion.
>
> i.e
> @Element(description = "server version")
> private String version = "5.2.0";
>
> is better than
> @Element(description = "server version")
> private String version = CarbonConfigurationConstants.DEFAULT_VERSION;
>
> Cheers,
> Ruwan
>
> On Mon, Nov 28, 2016 at 9:08 PM, Dilan Udara Ariyaratne 
> wrote:
>
>> Hi Danesh,
>>
>> Referring to the following,
>>
>> @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";
>>
>> ...
>>
>> }
>>
>> In a developer's perspective, it would be more meaningful to define any
>> default value as a separate CONSTANT in the code level and
>> set any bean property similar to above with such a constant for better
>> readability.
>>
>> For ex:
>>
>> @Configuration(namespace = "wso2.carbon", description = "Carbon 
>> Configuration Parameters")
>> public class CarbonConfiguration {
>>
>> @Element(description = "value to uniquely identify a server", required = 
>> true)
>> private String id = CarbonConfigurationConstants.DEFAULT_ID;
>> @Element(description = "server name")
>> private String name = CarbonConfigurationConstants.DEFAULT_NAME;
>> @Element(description = "server version")
>> private String version = CarbonConfigurationConstants.DEFAULT_VERSION;
>> ...
>> }
>>
>> In the meantime, also have the following question.
>>
>> 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 ?
>>
>> Thanks,
>> Dilan.
>>
>> *Dilan U. Ariyaratne*
>> Senior Software Engineer
>> WSO2 Inc. 
>> Mobile: +94766405580 <%2B94766405580>
>> lean . enterprise . middleware
>>
>>
>> On Mon, Nov 28, 2016 at 10:58 AM, Danesh Kuruppu  wrote:
>>
>>> Hi Rukshan,
>>>
>>> No. We are going to include this in next kernel release(5.2.0).
>>>
>>> Thanks
>>> Danesh
>>>
>>> On Mon, Nov 28, 2016 at 10:26 AM, Rukshan Premathunga 
>>> wrote:
>>>
 Hi Danesh,

 Is this feature is available now? if so can you mention the kernel
 version please?

 Thanks and Regards

 On Tue, Nov 22, 2016 at 12:22 PM, Danesh Kuruppu 
 wrote:

> Hi Nuwan,
>
> Can you also provide an example bean class for the netty listener?
>> That would make it clear how the bean class and its nested classes would 
>> be
>> annotated when array elements come into play.
>>
>
> Please check TransportsConfiguration sample below. We need to mention
> the default values of an array or collection in class constructor as 
> below.
>
> @Configuration(namespace = "wso2.transports.netty", description = "Netty 
> Transport Configurations")
> public class TransportsConfiguration {
>
> //default values of an array or collection need to mention in class 
> constructor
> public TransportsConfiguration() {
> ListenerConfiguration listenerConfiguration = 
> ListenerConfiguration();
> listenerConfigurations = new HashSet<>();
> listenerConfigurations.add(listenerConfiguration);
>
> SenderConfiguration senderConfiguration = SenderConfiguration();
> senderConfigurations = new HashSet<>();
> senderConfigurations.add(senderConfiguration);
>
> transportProperties = new HashSet<>();
> }
>
> 

Re: [Architecture] Carbon C5 - Server Configuration Model

[Ruwan Abeykoon]

Hi Dilan,
-1 moving the default value in the properties to constants, since they are
not constants. Most of the values within those defaults will be changed
over the time, when we learn more about the system behavior, over many
release cycles.

For the propose of readability and maintainability the original code looks
better than the suggestion.

i.e
@Element(description = "server version")
private String version = "5.2.0";

is better than
@Element(description = "server version")
private String version = CarbonConfigurationConstants.DEFAULT_VERSION;

Cheers,
Ruwan

On Mon, Nov 28, 2016 at 9:08 PM, Dilan Udara Ariyaratne 
wrote:

> Hi Danesh,
>
> Referring to the following,
>
> @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";
>
> ...
>
> }
>
> In a developer's perspective, it would be more meaningful to define any
> default value as a separate CONSTANT in the code level and
> set any bean property similar to above with such a constant for better
> readability.
>
> For ex:
>
> @Configuration(namespace = "wso2.carbon", description = "Carbon Configuration 
> Parameters")
> public class CarbonConfiguration {
>
> @Element(description = "value to uniquely identify a server", required = 
> true)
> private String id = CarbonConfigurationConstants.DEFAULT_ID;
> @Element(description = "server name")
> private String name = CarbonConfigurationConstants.DEFAULT_NAME;
> @Element(description = "server version")
> private String version = CarbonConfigurationConstants.DEFAULT_VERSION;
> ...
> }
>
> In the meantime, also have the following question.
>
> 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 ?
>
> Thanks,
> Dilan.
>
> *Dilan U. Ariyaratne*
> Senior Software Engineer
> WSO2 Inc. 
> Mobile: +94766405580 <%2B94766405580>
> lean . enterprise . middleware
>
>
> On Mon, Nov 28, 2016 at 10:58 AM, Danesh Kuruppu  wrote:
>
>> Hi Rukshan,
>>
>> No. We are going to include this in next kernel release(5.2.0).
>>
>> Thanks
>> Danesh
>>
>> On Mon, Nov 28, 2016 at 10:26 AM, Rukshan Premathunga 
>> wrote:
>>
>>> Hi Danesh,
>>>
>>> Is this feature is available now? if so can you mention the kernel
>>> version please?
>>>
>>> Thanks and Regards
>>>
>>> On Tue, Nov 22, 2016 at 12:22 PM, Danesh Kuruppu 
>>> wrote:
>>>
 Hi Nuwan,

 Can you also provide an example bean class for the netty listener? That
> would make it clear how the bean class and its nested classes would be
> annotated when array elements come into play.
>

 Please check TransportsConfiguration sample below. We need to mention
 the default values of an array or collection in class constructor as below.

 @Configuration(namespace = "wso2.transports.netty", description = "Netty 
 Transport Configurations")
 public class TransportsConfiguration {

 //default values of an array or collection need to mention in class 
 constructor
 public TransportsConfiguration() {
 ListenerConfiguration listenerConfiguration = 
 ListenerConfiguration();
 listenerConfigurations = new HashSet<>();
 listenerConfigurations.add(listenerConfiguration);

 SenderConfiguration senderConfiguration = SenderConfiguration();
 senderConfigurations = new HashSet<>();
 senderConfigurations.add(senderConfiguration);

 transportProperties = new HashSet<>();
 }

 @Element(description = "transport properties")
 private Set transportProperties = 
 Collections.EMPTY_SET;

 @Element(description = "listener configurations")
 private Set listenerConfigurations;

 @Element(description = "sender configurations")
 private Set senderConfigurations;

  }


> Have we thought about secure vault too?
>

 Yes, we resolve all secure valut values and system property values in
 deployment.yaml before generating bean class.

 Thanks
 --

 *Danesh Kuruppu*
 Senior Software Engineer | WSO2

 Email: dan...@wso2.com
 Mobile: +94 (77) 1690552
 Web: WSO2 Inc 


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


>>>
>>>
>>> 

Re: [Architecture] Carbon C5 - Server Configuration Model

[Dilan Udara Ariyaratne]

Hi Danesh,

Referring to the following,

@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";

...

}

In a developer's perspective, it would be more meaningful to define any
default value as a separate CONSTANT in the code level and
set any bean property similar to above with such a constant for better
readability.

For ex:

@Configuration(namespace = "wso2.carbon", description = "Carbon
Configuration Parameters")
public class CarbonConfiguration {

@Element(description = "value to uniquely identify a server",
required = true)
private String id = CarbonConfigurationConstants.DEFAULT_ID;
@Element(description = "server name")
private String name = CarbonConfigurationConstants.DEFAULT_NAME;
@Element(description = "server version")
private String version = CarbonConfigurationConstants.DEFAULT_VERSION;
...
}

In the meantime, also have the following question.

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 ?

Thanks,
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Mon, Nov 28, 2016 at 10:58 AM, Danesh Kuruppu  wrote:

> Hi Rukshan,
>
> No. We are going to include this in next kernel release(5.2.0).
>
> Thanks
> Danesh
>
> On Mon, Nov 28, 2016 at 10:26 AM, Rukshan Premathunga 
> wrote:
>
>> Hi Danesh,
>>
>> Is this feature is available now? if so can you mention the kernel
>> version please?
>>
>> Thanks and Regards
>>
>> On Tue, Nov 22, 2016 at 12:22 PM, Danesh Kuruppu  wrote:
>>
>>> Hi Nuwan,
>>>
>>> Can you also provide an example bean class for the netty listener? That
 would make it clear how the bean class and its nested classes would be
 annotated when array elements come into play.

>>>
>>> Please check TransportsConfiguration sample below. We need to mention
>>> the default values of an array or collection in class constructor as below.
>>>
>>> @Configuration(namespace = "wso2.transports.netty", description = "Netty 
>>> Transport Configurations")
>>> public class TransportsConfiguration {
>>>
>>> //default values of an array or collection need to mention in class 
>>> constructor
>>> public TransportsConfiguration() {
>>> ListenerConfiguration listenerConfiguration = 
>>> ListenerConfiguration();
>>> listenerConfigurations = new HashSet<>();
>>> listenerConfigurations.add(listenerConfiguration);
>>>
>>> SenderConfiguration senderConfiguration = SenderConfiguration();
>>> senderConfigurations = new HashSet<>();
>>> senderConfigurations.add(senderConfiguration);
>>>
>>> transportProperties = new HashSet<>();
>>> }
>>>
>>> @Element(description = "transport properties")
>>> private Set transportProperties = 
>>> Collections.EMPTY_SET;
>>>
>>> @Element(description = "listener configurations")
>>> private Set listenerConfigurations;
>>>
>>> @Element(description = "sender configurations")
>>> private Set senderConfigurations;
>>>
>>>  }
>>>
>>>
 Have we thought about secure vault too?

>>>
>>> Yes, we resolve all secure valut values and system property values in
>>> deployment.yaml before generating bean class.
>>>
>>> Thanks
>>> --
>>>
>>> *Danesh Kuruppu*
>>> Senior Software Engineer | WSO2
>>>
>>> Email: dan...@wso2.com
>>> Mobile: +94 (77) 1690552
>>> Web: WSO2 Inc 
>>>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Rukshan Chathuranga.
>> Software Engineer.
>> WSO2, Inc.
>>
>
>
>
> --
>
> *Danesh Kuruppu*
> Senior Software Engineer | WSO2
>
> Email: dan...@wso2.com
> Mobile: +94 (77) 1690552
> Web: WSO2 Inc 
>
>
> ___
> 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

Re: [Architecture] Carbon C5 - Server Configuration Model

[Danesh Kuruppu]

Hi Rukshan,

No. We are going to include this in next kernel release(5.2.0).

Thanks
Danesh

On Mon, Nov 28, 2016 at 10:26 AM, Rukshan Premathunga 
wrote:

> Hi Danesh,
>
> Is this feature is available now? if so can you mention the kernel version
> please?
>
> Thanks and Regards
>
> On Tue, Nov 22, 2016 at 12:22 PM, Danesh Kuruppu  wrote:
>
>> Hi Nuwan,
>>
>> Can you also provide an example bean class for the netty listener? That
>>> would make it clear how the bean class and its nested classes would be
>>> annotated when array elements come into play.
>>>
>>
>> Please check TransportsConfiguration sample below. We need to mention the
>> default values of an array or collection in class constructor as below.
>>
>> @Configuration(namespace = "wso2.transports.netty", description = "Netty 
>> Transport Configurations")
>> public class TransportsConfiguration {
>>
>> //default values of an array or collection need to mention in class 
>> constructor
>> public TransportsConfiguration() {
>> ListenerConfiguration listenerConfiguration = 
>> ListenerConfiguration();
>> listenerConfigurations = new HashSet<>();
>> listenerConfigurations.add(listenerConfiguration);
>>
>> SenderConfiguration senderConfiguration = SenderConfiguration();
>> senderConfigurations = new HashSet<>();
>> senderConfigurations.add(senderConfiguration);
>>
>> transportProperties = new HashSet<>();
>> }
>>
>> @Element(description = "transport properties")
>> private Set transportProperties = 
>> Collections.EMPTY_SET;
>>
>> @Element(description = "listener configurations")
>> private Set listenerConfigurations;
>>
>> @Element(description = "sender configurations")
>> private Set senderConfigurations;
>>
>>  }
>>
>>
>>> Have we thought about secure vault too?
>>>
>>
>> Yes, we resolve all secure valut values and system property values in
>> deployment.yaml before generating bean class.
>>
>> Thanks
>> --
>>
>> *Danesh Kuruppu*
>> Senior Software Engineer | WSO2
>>
>> Email: dan...@wso2.com
>> Mobile: +94 (77) 1690552
>> Web: WSO2 Inc 
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Rukshan Chathuranga.
> Software Engineer.
> WSO2, Inc.
>



-- 

*Danesh Kuruppu*
Senior Software Engineer | WSO2

Email: dan...@wso2.com
Mobile: +94 (77) 1690552
Web: WSO2 Inc 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Carbon C5 - Server Configuration Model

[Rukshan Premathunga]

Hi Danesh,

Is this feature is available now? if so can you mention the kernel version
please?

Thanks and Regards

On Tue, Nov 22, 2016 at 12:22 PM, Danesh Kuruppu  wrote:

> Hi Nuwan,
>
> Can you also provide an example bean class for the netty listener? That
>> would make it clear how the bean class and its nested classes would be
>> annotated when array elements come into play.
>>
>
> Please check TransportsConfiguration sample below. We need to mention the
> default values of an array or collection in class constructor as below.
>
> @Configuration(namespace = "wso2.transports.netty", description = "Netty 
> Transport Configurations")
> public class TransportsConfiguration {
>
> //default values of an array or collection need to mention in class 
> constructor
> public TransportsConfiguration() {
> ListenerConfiguration listenerConfiguration = ListenerConfiguration();
> listenerConfigurations = new HashSet<>();
> listenerConfigurations.add(listenerConfiguration);
>
> SenderConfiguration senderConfiguration = SenderConfiguration();
> senderConfigurations = new HashSet<>();
> senderConfigurations.add(senderConfiguration);
>
> transportProperties = new HashSet<>();
> }
>
> @Element(description = "transport properties")
> private Set transportProperties = 
> Collections.EMPTY_SET;
>
> @Element(description = "listener configurations")
> private Set listenerConfigurations;
>
> @Element(description = "sender configurations")
> private Set senderConfigurations;
>
>  }
>
>
>> Have we thought about secure vault too?
>>
>
> Yes, we resolve all secure valut values and system property values in
> deployment.yaml before generating bean class.
>
> Thanks
> --
>
> *Danesh Kuruppu*
> Senior Software Engineer | WSO2
>
> Email: dan...@wso2.com
> Mobile: +94 (77) 1690552
> Web: WSO2 Inc 
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Rukshan Chathuranga.
Software Engineer.
WSO2, Inc.
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Carbon C5 - Server Configuration Model

[Danesh Kuruppu]

Hi Nuwan,

Can you also provide an example bean class for the netty listener? That
> would make it clear how the bean class and its nested classes would be
> annotated when array elements come into play.
>

Please check TransportsConfiguration sample below. We need to mention the
default values of an array or collection in class constructor as below.

@Configuration(namespace = "wso2.transports.netty", description =
"Netty Transport Configurations")
public class TransportsConfiguration {

//default values of an array or collection need to mention in
class constructor
public TransportsConfiguration() {
ListenerConfiguration listenerConfiguration = ListenerConfiguration();
listenerConfigurations = new HashSet<>();
listenerConfigurations.add(listenerConfiguration);

SenderConfiguration senderConfiguration = SenderConfiguration();
senderConfigurations = new HashSet<>();
senderConfigurations.add(senderConfiguration);

transportProperties = new HashSet<>();
}

@Element(description = "transport properties")
private Set transportProperties = Collections.EMPTY_SET;

@Element(description = "listener configurations")
private Set listenerConfigurations;

@Element(description = "sender configurations")
private Set senderConfigurations;

 }


> Have we thought about secure vault too?
>

Yes, we resolve all secure valut values and system property values in
deployment.yaml before generating bean class.

Thanks
-- 

*Danesh Kuruppu*
Senior Software Engineer | WSO2

Email: dan...@wso2.com
Mobile: +94 (77) 1690552
Web: WSO2 Inc 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Carbon C5 - Server Configuration Model

[Danesh Kuruppu]

Hi Susinda,

In configuration class, do we treat all properties as Strings? Or what if
> we make the parsing within this config class.?
>

No, we can have any type. and we don't need to parse within the config
class. My example bit confusing, it has only String values. meant to show
how to add annotations.
We can write normal bean class with default values, only addition is to put
annotations to the class.
We use snakeYAML apis to load bean class from yaml configs.

Thanks
-- 

*Danesh Kuruppu*
Senior Software Engineer | WSO2

Email: dan...@wso2.com
Mobile: +94 (77) 1690552
Web: WSO2 Inc 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Carbon C5 - Server Configuration Model

[Danesh Kuruppu]

Hi Dilan,

Why are we going to duplicate all user-settable, default configuration
> values both at yaml level as well as Java bean level ?
> Cannot we make the yaml as the one and only reference point ?
>

We are not duplicating the default configuration values. only place we
specify default values is in Java bean level. There is no yaml file with
default values. We put configs in the deployment.yaml, only if we need to
override the default value.
-- 

*Danesh Kuruppu*
Senior Software Engineer | WSO2

Email: dan...@wso2.com
Mobile: +94 (77) 1690552
Web: WSO2 Inc 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Carbon C5 - Server Configuration Model

[Nuwan Dias]

Can you also provide an example bean class for the netty listener? That
would make it clear how the bean class and its nested classes would be
annotated when array elements come into play.

Have we thought about secure vault too?

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 Kuruppu*
> Senior Software Engineer | WSO2
>
> Email: dan...@wso2.com
> Mobile: +94 (77) 1690552
> Web: WSO2 Inc 
>
>
> ___
> 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

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 Kuruppu*
>> Senior Software Engineer | WSO2
>>
>> Email: dan...@wso2.com
>> Mobile: +94 (77) 1690552
>> Web: WSO2 Inc 
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Sajith Janaprasad Ariyarathna
> Software Engineer; WSO2, Inc.;  http://wso2.com/
> 
>



-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* *
*email: **az...@wso2.com* 
* cell: +94 77 3320919blog: **http://blog.afkham.org*

Re: [Architecture] Carbon C5 - Server Configuration Model

[Susinda Perera]

Hi Danesh

In configuration class, do we treat all properties as Strings? Or what if
we make the parsing within this config class.?

Thanks
Susinda

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.
>
> 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 Kuruppu*
>> Senior Software Engineer | WSO2
>>
>> Email: dan...@wso2.com
>> Mobile: +94 (77) 1690552
>> Web: WSO2 Inc 
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Sajith Janaprasad Ariyarathna
> Software Engineer; WSO2, Inc.;  http://wso2.com/
> 
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Susinda Perera*
Software Engineer
B.Sc.(Eng), M.Sc(Computer Science), AMIE(SL)
Mobile:(+94)716049075
Blog: susinda.blogspot.com
WSO2 Inc. http://wso2.com/
Tel : 94 11 214 5345 Fax :94 11 

Re: [Architecture] Carbon C5 - Server Configuration Model

[Dilan Udara Ariyaratne]

Hi Danesh,

Why are we going to duplicate all user-settable, default configuration
values both at yaml level as well as Java bean level ?
Cannot we make the yaml as the one and only reference point ?

Thanks,
Dilan.


*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


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.
>
> 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 Kuruppu*
>> Senior Software Engineer | WSO2
>>
>> Email: dan...@wso2.com
>> Mobile: +94 (77) 1690552
>> Web: WSO2 Inc 
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Sajith Janaprasad Ariyarathna
> Software Engineer; WSO2, Inc.;  http://wso2.com/
> 
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> 

Re: [Architecture] Carbon C5 - Server Configuration Model

[SajithAR Ariyarathna]

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.

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 Kuruppu*
> Senior Software Engineer | WSO2
>
> Email: dan...@wso2.com
> Mobile: +94 (77) 1690552
> Web: WSO2 Inc 
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Sajith Janaprasad Ariyarathna
Software Engineer; WSO2, Inc.;  http://wso2.com/

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