hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Bowen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-24) make Configuration an interface
Date Wed, 10 May 2006 20:06:04 GMT
    [ http://issues.apache.org/jira/browse/HADOOP-24?page=comments#action_12378968 ] 

David Bowen commented on HADOOP-24:
-----------------------------------


The code contains getObject and setObject methods.  Is this a good idea - considering that
it means that the ConfigurationImpl cannot be written out and read back without losing those
values?  I think it would be better to remove these and maintain the ability to serialize
and deserialize.  (Is there a reason not to have Configuration extend Writable?)

What is a use case for ConfigurationBase.getProperties() which returns an object of unknown
type?  It might be better to have something like String[] getPropertyNames(String regex).
 (And this should be in Configuration also.)  This allows for things like treating the property
name space as a hierarchy, so that e.g. you can find all the properties beginning with some
string.

- David




> make Configuration an interface
> -------------------------------
>
>          Key: HADOOP-24
>          URL: http://issues.apache.org/jira/browse/HADOOP-24
>      Project: Hadoop
>         Type: Improvement

>   Components: conf
>     Reporter: Doug Cutting
>  Attachments: 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