hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-24) make Configuration an interface
Date Wed, 16 Apr 2008 13:09:21 GMT

    [ 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.


Mime
View raw message