Mailing-List: contact core-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: core-dev@hadoop.apache.org
Message-ID: <181227361.1208351361623.JavaMail.jira@brutus>
Date: Wed, 16 Apr 2008 06:09:21 -0700 (PDT)
From: "Steve Loughran (JIRA)" <jira@apache.org>
To: core-dev@hadoop.apache.org
Subject: [jira] Commented: (HADOOP-24) make Configuration an interface
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Steve Loughran commented on HADOOP-24:
--------------------------------------

I concur; a WONTFIX is a better outcome, with

1. a new improvement 'support multiple configuration back ends' added.

2. a separate issue 'add a specific ConfigurationException that extends RuntimeException to throw for Configuration problems'...that can be added before any back-end improvements, and could also be used to address HADOOP-2081 and any number format exceptions thrown from any HADOOP-2461 -related changes. This is simpler and would seem to be higher priority. Its easier to test, too.

> make Configuration an interface
> -------------------------------
>
>                 Key: HADOOP-24
>                 URL: https://issues.apache.org/jira/browse/HADOOP-24
>             Project: Hadoop Core
>          Issue Type: Improvement
>          Components: conf
>    Affects Versions: 0.7.2
>            Reporter: Doug Cutting
>            Assignee: Doug Cutting
>         Attachments: conf-with-factory.patch, configuration.java, configuration.patch, HADOOP-24-2.patch, HADOOP-24-3.patch, HADOOP-24-4.patch, HADOOP-24.patch, HADOOP-24.patch
>
>
> The Configuration class should become an interface, e.g.:
> public interface Configuration {
>   String get(String nam);
>   String set(String name, String value);
>   int getInt(String name);
>   void setInt(String name, int value);
>   float getFloat(String name);
>   void setFloat(String name, float value);
>   //... other utility methods based on get(String) and set(String,String) ...
> }
> An abstract class named ConfigurationBase should be implemented as follows:
> public abstract class ConfigurationBase implements Configuration {
>   abstract public String get(String nam);
>   abstract public String set(String name, String value);
>   public  int getInt(String name) { ... implementation in terms of get(String) ... }
>   public void setInt(String name, int value) {... implementation in terms of set(String, String) ...}
>   public float getFloat(String name)  { ... implementation in terms of get(String) ... }
>   public void setFloat(String name, float value)  {... implementation in terms of set(String, String) ...}
>   //... other utility methods based on get(String) and set(String,String) ...
> }
> A concrete, default implementation will be provided as follows:
> public class ConfigurationImpl implements Writable extends ConfigurationBase {
>   private Properties properties;
>   // implement abstract methods from ConfigurationBase
>   public String get(String name) { ... implemented in terms of props ...}
>   public String set(String name, String value) { .. implemented in terms of props ... }
>   // Writable methods
>   public write(DataOutputStream out);
>   public readFields(DataInputStream in);
>   // permit chaining of configurations
>   public Configuration getDefaults();
>   public void setDefaults(Configuration defaults);
> }
> Only code which creates configurations should need to be updated, so this shouldn't be a huge change.

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