Mailing-List: contact hadoop-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hadoop-dev@lucene.apache.org
Message-ID: <1702136.1199901880123.JavaMail.jira@brutus>
Date: Wed, 9 Jan 2008 10:04:40 -0800 (PST)
From: "Doug Cutting (JIRA)" <jira@apache.org>
To: hadoop-dev@lucene.apache.org
Subject: [jira] Commented: (HADOOP-2385) Validate configuration parameters
In-Reply-To: <10496725.1197074923378.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HADOOP-2385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557359#action_12557359 ] 

Doug Cutting commented on HADOOP-2385:
--------------------------------------

> The Configuration itself should remain the same for each component.
> It just exposes get methods specific to the component.

Yes, that would work for getters, but not for setters.  In many cases we need setters too, and it would be confusing to implement getters and setters using different styles.  Setters are best implemented as static methods, thus, for symmetry, getters must be also.

> I do not support the idea of placing static getters for configuration parameters in the (top-level) component

I'm okay having per-package config classes (e.g.m DFSConfig) that centralizes configuration setters and getters for that package, since, in some cases, the classes which consume these (e.g., FSNamesystem) are not public classes.


> Validate configuration parameters
> ---------------------------------
>
>                 Key: HADOOP-2385
>                 URL: https://issues.apache.org/jira/browse/HADOOP-2385
>             Project: Hadoop
>          Issue Type: Improvement
>          Components: dfs
>    Affects Versions: 0.16.0
>            Reporter: Robert Chansler
>
> Configuration parameters should be fully validated before name nodes or data nodes begin service.
> Required parameters must be present.
> Required and optional parameters must have values of proper type and range.
> Undefined parameters must not be present.
> (I was recently observing some confusion whose root cause was a mis-spelled parameter.)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.