hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Cutting (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-24) make Configuration an interface
Date Tue, 24 Oct 2006 21:03:20 GMT
    [ http://issues.apache.org/jira/browse/HADOOP-24?page=comments#action_12444508 ] 
            
Doug Cutting commented on HADOOP-24:
------------------------------------

When I apply this to trunk things don't compile.  I think you forgot to include ConfigurationImpl.java.

I also wonder if, since we're editing all the places where a configuration is constructed,
we might change things to use a factory.  So, instead of 'new ConfigurationImpl()' we'd have
something like 'ConfigurationFactory.get()'.  That way, we could in the future change the
default implementation without changing all of these places again.  E.g., if you're nesting
Hadoop in JMX then you might specify a JMX configuration factory as the default.  Does that
make sense?


> make Configuration an interface
> -------------------------------
>
>                 Key: HADOOP-24
>                 URL: http://issues.apache.org/jira/browse/HADOOP-24
>             Project: Hadoop
>          Issue Type: Improvement
>          Components: conf
>    Affects Versions: 0.7.2
>            Reporter: Doug Cutting
>         Attachments: 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.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message