Hi Dileepa,

On Thu, Jan 26, 2012 at 5:08 PM, Dileepa Jayakody <[email protected]> wrote:

> Hi Nirmal,
>
> The list of configurations to be validated are yet to be finalised.
> The set of configs added to the current config-validation.xml are a set of
> sample validation parameters.
> Will finalise the set of configs to be validated in each Validator  and
> give an update.
> First, I'm going to re-factor the current architecture to incorporate the
> suggestions made at the review; the list of configs to be validated can be
> finalised thereafter.
>

Great!


>
> Thanks,
> Dileepa
>
>
> On Thu, Jan 26, 2012 at 3:36 PM, Nirmal Fernando <[email protected]> wrote:
>
>> Hi,
>>
>> On Thu, Jan 26, 2012 at 3:30 PM, KasunG Gajasinghe <[email protected]>wrote:
>>
>>> This is the notes for architecture and code of the new component, carbon
>>> bootup validator held on 26th Jan 2011. Please amend it as necessary.
>>> Relevant JIRA - https://wso2.org/jira/browse/CARBONROADMAP-15
>>>
>>> In the current arch, only the hard-coded parameters can be checked.
>>> Parameters should be broken down to validators for extensibility. The
>>> parameters here refers to heapMemory etc. See
>>> https://wso2.org/jira/secure/attachment/18252/config_validation.xml
>>>
>>
>> Why we need both RAM and freeRAM validation? Can't we have only freeRAM
>> validation? (same question apply to Swap as well)
>>
>> Thanks.
>>
>>
>>>  The point is, for a given validator, create a hashmap for the
>>> parameters name-value pair, and pass it to the validator. So, there will be
>>> a HashMap per Validator. Inside a validator retrieve the current system
>>> hardware and system properties, and compare the values. This new arch
>>> invalidates the need of separate DataCollectors. Data collecting is also
>>> done inside a validator.
>>>
>>> Then, the interface for validators will look like -
>>> protected init (Map recommendedValues),
>>> protected abstract Map<String, ValidationResult> validate(),
>>>     - No printing inside the validators. This isnt the presentation
>>> layer.
>>>     - just validate the parameters and return true/false
>>>     - The guy using these values can decide what to do
>>>
>>> The stubs of how the invocation happen (like Azeez's 'How to make a tea'
>>> example ;) ) will be like what's in the provided snapshot.
>>>
>>>
>>> Apart from the above architectural decisions, following decisions were
>>> taken.
>>>
>>>    - Rename the config file config_validation.xml to
>>>    config-validation.xml. Separating words by dash (-) is the general 
>>> standard
>>>    for carbon and axis2.
>>>    - Concerns raised whether the measurement unit (like MBs, MHz)
>>>    should be added as a parameter instead of a comment for configurability.
>>>    But agreed that it's OK for the moment.
>>>    -
>>>    - Add a new Validator for validating System Properties. Some use
>>>    cases - If an user removes a sh script, there can be problems at runtime,
>>>    sys properties like carbon.home should be available.
>>>    - Add an optional validator for validating GC optimization
>>>    parameters. Add a commented xml such that end-user can uncomment if 
>>> needed.
>>>    - Add PermGen size as well to the JVMValidator.
>>>    - Display a message stating the tested OSes if the OS at runtime
>>>    hasn't been tested.
>>>
>>>
>>> Code level notes -
>>>
>>>    - Catching exceptions ---    Properly handle and throw the
>>>    exceptions. Rename ConfigurationParamaeterException to something like
>>>    UnrecongnizedParameterException, and make it a RuntimeException because
>>>    this isnt about business logic
>>>    - Make 'activate' variable in ConfigValidationXMLProcessor
>>>    class final
>>>    - Create Logger instance per class, not per instance. Such that make
>>>    it private static final.
>>>    - Remove the construct in ConfigValidationXMLProcessor
>>>    - Have interfaces (like List, Map etc.) for reference class instead
>>>    of having ArrayList, HashMap etc.
>>>
>>>
>>>    - Use ulimit -n for max number of opened files. It includes the
>>>    opened socket count as well. SystemDataCollector class
>>>
>>>
>>> Regards,
>>> --KasunG
>>>
>>>
>>> --
>>> *Kasun Gajasinghe*
>>> Software Engineer; WSO2 Inc.; http://wso2.com
>>>
>>> ,
>>> *email: **kasung AT spamfree wso2.com** cell: **+94 (77) 678-0813*
>>> *blog: **http://blog.kasunbg.org* <http://blog.kasunbg.org>
>>>
>>> *
>>> twitter: **http://twitter.com/kasunbg* <http://twitter.com/kasunbg>
>>>
>>> *
>>> *
>>>
>>>
>>> _______________________________________________
>>> Carbon-dev mailing list
>>> [email protected]
>>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>>>
>>>
>>
>>
>> --
>>
>> regards,
>> Nirmal
>>
>> Software Engineer, WSO2 Inc.
>> mobile: +94715779733
>>
>>
>> _______________________________________________
>> Carbon-dev mailing list
>> [email protected]
>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>>
>>
>
>
> --
> Dileepa Jayakody,
> Software Engineer, WSO2 Inc.
> Lean . Enterprise . Middleware
>
> Mobile : +94777-857616
>
>
> _______________________________________________
> Carbon-dev mailing list
> [email protected]
> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>
>


-- 

regards,
Nirmal

Software Engineer, WSO2 Inc.
mobile: +94715779733
_______________________________________________
Carbon-dev mailing list
[email protected]
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

Reply via email to