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 <dil...@wso2.com>
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. <http://wso2.com/>
> Mobile: +94766405580 <%2B94766405580>
> lean . enterprise . middleware
>
>
> On Tue, Nov 29, 2016 at 7:27 AM, Ruwan Abeykoon <ruw...@wso2.com> 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 <dil...@wso2.com>
>> 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. <http://wso2.com/>
>>> Mobile: +94766405580 <%2B94766405580>
>>> lean . enterprise . middleware
>>>
>>>
>>> On Mon, Nov 28, 2016 at 10:58 AM, Danesh Kuruppu <dan...@wso2.com>
>>> 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 <ruks...@wso2.com
>>>> > 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 <dan...@wso2.com>
>>>>> 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<TransportProperty> transportProperties = 
>>>>>> Collections.EMPTY_SET;
>>>>>>
>>>>>>     @Element(description = "listener configurations")
>>>>>>     private Set<ListenerConfiguration> listenerConfigurations;
>>>>>>
>>>>>>     @Element(description = "sender configurations")
>>>>>>     private Set<SenderConfiguration> 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 <https://wso2.com/signature>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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 <https://wso2.com/signature>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>
>>
>> --
>>
>> *Ruwan Abeykoon*
>> *Associate Director/Architect**,*
>> *WSO2, Inc. http://wso2.com <https://wso2.com/signature> *
>> *lean.enterprise.middleware.*
>>
>>
>> _______________________________________________
>> 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
>
>


-- 
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: ram...@wso2.com
P: +94 777542851
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to