Re: [Architecture] Carbon C5 - Server Configuration Model

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

Re: [Architecture] Carbon C5 - Server Configuration Model

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

Re: [Architecture] Carbon C5 - Server Configuration Model

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

Re: [Architecture] Carbon C5 - Server Configuration Model

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

Re: [Architecture] Carbon C5 - Server Configuration Model

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

Re: [Architecture] Carbon C5 - Server Configuration Model

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.

Re: [Architecture] Carbon C5 - Server Configuration Model

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

Re: [Architecture] Carbon C5 - Server Configuration Model

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

Re: [Architecture] Carbon C5 - Server Configuration Model

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

Re: [Architecture] Carbon C5 - Server Configuration Model

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,

Re: [Architecture] Carbon C5 - Server Configuration Model

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

Re: [Architecture] Carbon C5 - Server Configuration Model

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

Re: [Architecture] Carbon C5 - Server Configuration Model

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

Re: [Architecture] Carbon C5 - Server Configuration Model

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

Re: [Architecture] Carbon C5 - Server Configuration Model

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

Re: [Architecture] Carbon C5 - Server Configuration Model

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.

Re: [Architecture] Carbon C5 - Server Configuration Model

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

Re: [Architecture] Carbon C5 - Server Configuration Model

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

Re: [Architecture] Carbon C5 - Server Configuration Model

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

Re: [Architecture] Carbon C5 - Server Configuration Model

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

Re: [Architecture] Carbon C5 - Server Configuration Model

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

Re: [Architecture] Carbon C5 - Server Configuration Model

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

Re: [Architecture] Carbon C5 - Server Configuration Model

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

Re: [Architecture] Carbon C5 - Server Configuration Model

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

Re: [Architecture] Carbon C5 - Server Configuration Model

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

Re: [Architecture] Carbon C5 - Server Configuration Model

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

Re: [Architecture] Carbon C5 - Server Configuration Model

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

Re: [Architecture] Carbon C5 - Server Configuration Model

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

Re: [Architecture] Carbon C5 - Server Configuration Model

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

Re: [Architecture] Carbon C5 - Server Configuration Model

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.

Re: [Architecture] Carbon C5 - Server Configuration Model

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

[Architecture] Carbon C5 - Server Configuration Model

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)