Hadoop Common
  1. Hadoop Common
  2. HADOOP-6420

String-to-String Maps should be embeddable in Configuration

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.21.0
    • Component/s: conf
    • Labels:
      None
    • Hadoop Flags:
      Reviewed

      Description

      Per MAPREDUCE-1126, we need to be able to take a map of (key, value) pairs and embed that inside a Configuration object.

      1. HADOOP-6420.patch
        4 kB
        Aaron Kimball
      2. HADOOP-6420.2.patch
        5 kB
        Aaron Kimball
      3. HADOOP-6420.3.patch
        5 kB
        Aaron Kimball
      4. HADOOP-6420.4.patch
        5 kB
        Aaron Kimball
      5. HADOOP-6420.5.patch
        7 kB
        Aaron Kimball
      6. HADOOP-6420.6.patch
        7 kB
        Aaron Kimball
      7. HADOOP-6420.7.patch
        7 kB
        Aaron Kimball
      8. HADOOP-6420.8.patch
        8 kB
        Aaron Kimball
      9. HADOOP-6420.9.patch
        8 kB
        Aaron Kimball
      10. HADOOP-6420.10.patch
        7 kB
        Aaron Kimball

        Issue Links

          Activity

          Hide
          Aaron Kimball added a comment -

          Implementation and test case.

          Show
          Aaron Kimball added a comment - Implementation and test case.
          Hide
          Hadoop QA added a comment -

          +1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12427399/HADOOP-6420.patch
          against trunk revision 888565.

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 3 new or modified tests.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 findbugs. The patch does not introduce any new Findbugs warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          +1 core tests. The patch passed core unit tests.

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/180/testReport/
          Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/180/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
          Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/180/artifact/trunk/build/test/checkstyle-errors.html
          Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/180/console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12427399/HADOOP-6420.patch against trunk revision 888565. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/180/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/180/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/180/artifact/trunk/build/test/checkstyle-errors.html Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/180/console This message is automatically generated.
          Hide
          Tom White added a comment -

          A couple of comments on the patch:

          • In the documentation for setMap() say that "name" should not have a trailing period.
          • Deprecation needs to be handled for getMap(). Also variable substitution. This could be fixed by calling Configuration's get(), rather than the underlying Properties. (You could use the Properties object to get the keys still.) It would be good to add unit tests for these cases.
          Show
          Tom White added a comment - A couple of comments on the patch: In the documentation for setMap() say that "name" should not have a trailing period. Deprecation needs to be handled for getMap(). Also variable substitution. This could be fixed by calling Configuration's get(), rather than the underlying Properties. (You could use the Properties object to get the keys still.) It would be good to add unit tests for these cases.
          Hide
          Aaron Kimball added a comment -

          Good points in the review. getMap() now handles variable substitution as well as deprecation.

          Since getMap() itself takes the "key" to resolve, I have implemented deprecation-resolution at this level. e.g., "prefix.foo" and "prefix.bar" do not need to be individually deprecated in favor of "newprefix.foo", "newprefix.bar"; instead, you just deprecate "prefix" for "newprefix" as if it were a monolithic entity in the configuration, and calls to getMap("prefix") will be resolved to look up getMap("newprefix") instead.

          If "newprefix.foo" is further deprecated in favor of "some.other.key", this is not resolved by getMap("newprefix") or getMap("prefix").

          Show
          Aaron Kimball added a comment - Good points in the review. getMap() now handles variable substitution as well as deprecation. Since getMap() itself takes the "key" to resolve, I have implemented deprecation-resolution at this level. e.g., "prefix.foo" and "prefix.bar" do not need to be individually deprecated in favor of "newprefix.foo", "newprefix.bar"; instead, you just deprecate "prefix" for "newprefix" as if it were a monolithic entity in the configuration, and calls to getMap("prefix") will be resolved to look up getMap("newprefix") instead. If "newprefix.foo" is further deprecated in favor of "some.other.key", this is not resolved by getMap("newprefix") or getMap("prefix") .
          Hide
          Hadoop QA added a comment -

          +1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12427516/HADOOP-6420.2.patch
          against trunk revision 888697.

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 3 new or modified tests.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 findbugs. The patch does not introduce any new Findbugs warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          +1 core tests. The patch passed core unit tests.

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/181/testReport/
          Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/181/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
          Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/181/artifact/trunk/build/test/checkstyle-errors.html
          Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/181/console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12427516/HADOOP-6420.2.patch against trunk revision 888697. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/181/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/181/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/181/artifact/trunk/build/test/checkstyle-errors.html Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/181/console This message is automatically generated.
          Hide
          Tom White added a comment -

          Since getMap() itself takes the "key" to resolve, I have implemented deprecation-resolution at this level.

          +1 This sounds like the right approach to me. Thanks for writing the extra test.

          Show
          Tom White added a comment - Since getMap() itself takes the "key" to resolve, I have implemented deprecation-resolution at this level. +1 This sounds like the right approach to me. Thanks for writing the extra test.
          Hide
          Aaron Kimball added a comment -

          new patch; sync'd with trunk

          Show
          Aaron Kimball added a comment - new patch; sync'd with trunk
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12427639/HADOOP-6420.3.patch
          against trunk revision 889378.

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 3 new or modified tests.

          -1 patch. The patch command could not apply the patch.

          Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h1.grid.sp2.yahoo.net/25/console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12427639/HADOOP-6420.3.patch against trunk revision 889378. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. -1 patch. The patch command could not apply the patch. Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h1.grid.sp2.yahoo.net/25/console This message is automatically generated.
          Hide
          Aaron Kimball added a comment -

          patch with --no-prefix

          Show
          Aaron Kimball added a comment - patch with --no-prefix
          Hide
          Hadoop QA added a comment -

          +1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12427641/HADOOP-6420.4.patch
          against trunk revision 889378.

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 3 new or modified tests.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 findbugs. The patch does not introduce any new Findbugs warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          +1 core tests. The patch passed core unit tests.

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/191/testReport/
          Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/191/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
          Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/191/artifact/trunk/build/test/checkstyle-errors.html
          Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/191/console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12427641/HADOOP-6420.4.patch against trunk revision 889378. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/191/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/191/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/191/artifact/trunk/build/test/checkstyle-errors.html Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/191/console This message is automatically generated.
          Hide
          Arun C Murthy added a comment -

          Aaron, can you please explain the use case a little more? Why do we really need maps? Why isn't the requisite metadata serializable?

          Show
          Arun C Murthy added a comment - Aaron, can you please explain the use case a little more? Why do we really need maps? Why isn't the requisite metadata serializable?
          Hide
          Aaron Kimball added a comment -

          This is used for MAPREDUCE-1126. In HADOOP-6165, the serialization system was changed such that serialization metadata is defined as a Map<String, String> with an arbitrary set of (key, value) pairs inside.

          To support more serialization formats than just WritableSerialization, we need to allow these arbitrary maps of data to be specified by the user via the job's Configuration. Thus, much as how we have defined mechanisms to embed ints, booleans, and lists of strings in the Configuration, we need to expand the set of datatypes we can embed in the configuration to also include maps of string->string. This does so without needing to worry about escape characters or other clumsiness that would result via embedding a single (k, v) pair in the Configuration.

          Show
          Aaron Kimball added a comment - This is used for MAPREDUCE-1126 . In HADOOP-6165 , the serialization system was changed such that serialization metadata is defined as a Map<String, String> with an arbitrary set of (key, value) pairs inside. To support more serialization formats than just WritableSerialization, we need to allow these arbitrary maps of data to be specified by the user via the job's Configuration . Thus, much as how we have defined mechanisms to embed ints, booleans, and lists of strings in the Configuration, we need to expand the set of datatypes we can embed in the configuration to also include maps of string->string. This does so without needing to worry about escape characters or other clumsiness that would result via embedding a single (k, v) pair in the Configuration.
          Hide
          Chris Douglas added a comment -

          This does so without needing to worry about escape characters or other clumsiness that would result via embedding a single (k, v) pair in the Configuration.

          On the other hand, the current approach ignores inadvertent collisions and getMap is inefficient and not threadsafe.

          much as how we have defined mechanisms to embed ints, booleans, and lists of strings in the Configuration, we need to expand the set of datatypes we can embed in the configuration to also include maps of string->string

          This isn't embedding maps of string->string; it's selecting a subset of keys in a string->string map using an unenforced naming convention. It's par for (ab)uses of Configuration, but it's hackish.

          Have you looked into using a Stringifier or something along those lines? Escaping shouldn't be too clumsy...

          Show
          Chris Douglas added a comment - This does so without needing to worry about escape characters or other clumsiness that would result via embedding a single (k, v) pair in the Configuration. On the other hand, the current approach ignores inadvertent collisions and getMap is inefficient and not threadsafe. much as how we have defined mechanisms to embed ints, booleans, and lists of strings in the Configuration, we need to expand the set of datatypes we can embed in the configuration to also include maps of string->string This isn't embedding maps of string->string; it's selecting a subset of keys in a string->string map using an unenforced naming convention. It's par for (ab)uses of Configuration, but it's hackish. Have you looked into using a Stringifier or something along those lines? Escaping shouldn't be too clumsy...
          Hide
          Doug Cutting added a comment -

          > Have you looked into using a Stringifier or something along those lines?

          That could be fun to boostrap. DefaultStringifier uses SerializationFactory which could use DefaultStringifier to find the serializer's metadata.

          Whatever we use here we want to be easy for non-Java applications to use. The original reason for using a Map<String,String> model for configuration was that it is a proven format for inter-operable configuration (environment variables). So, if we used something like Stringifier, we'd need to convince ourselves that the serialization we used for this was available to all applications that might want to configure map-valued properties like serialization parameters.

          I don't much like filtering, but I also don't much like big blobby stuff in configs.

          Note that we don't need to filter the entire configuration unless someone iterates over the subset. The returned map view could instead be a wrapper map implementation that dynamically prefixes keys on access to the underlying configuration. If iteration is not required then we could simply have it throw UnsupportedOperationException. This would address the efficiency and thread-safety concerns.

          If we did need to support iteration, then perhaps we could change Configuration to use treemap, but that might open other cans of worms.

          Show
          Doug Cutting added a comment - > Have you looked into using a Stringifier or something along those lines? That could be fun to boostrap. DefaultStringifier uses SerializationFactory which could use DefaultStringifier to find the serializer's metadata. Whatever we use here we want to be easy for non-Java applications to use. The original reason for using a Map<String,String> model for configuration was that it is a proven format for inter-operable configuration (environment variables). So, if we used something like Stringifier, we'd need to convince ourselves that the serialization we used for this was available to all applications that might want to configure map-valued properties like serialization parameters. I don't much like filtering, but I also don't much like big blobby stuff in configs. Note that we don't need to filter the entire configuration unless someone iterates over the subset. The returned map view could instead be a wrapper map implementation that dynamically prefixes keys on access to the underlying configuration. If iteration is not required then we could simply have it throw UnsupportedOperationException. This would address the efficiency and thread-safety concerns. If we did need to support iteration, then perhaps we could change Configuration to use treemap, but that might open other cans of worms.
          Hide
          Chris Douglas added a comment -

          That could be fun to boostrap. DefaultStringifier uses SerializationFactory which could use DefaultStringifier to find the serializer's metadata. [...]

          This is not what I'm talking about. The Stringifier interface obviously doesn't require something as general as DefaultStringifier and nobody has argued that a Map<String,String> is wrong. The issue is whether the current patch offers the best approach to render the metadata to the serialization; its superiority to big, blobby stuff is not obvious. By noting that efforts to push non-primitive types into Configuration has a precedent and an interface, I did not intend to advocate for a pluggable meta-serialization layer on top of Configuration.

          Note that we don't need to filter the entire configuration unless someone iterates over the subset. [...]

          Returning a Map from Configuration and restricting its range is cleaner and easier to explain. If iteration isn't required, then this approach sounds good to me.

          If we did need to support iteration, then perhaps we could change Configuration to use treemap, but that might open other cans of worms.

          Agreed. After seeing MAPREDUCE-1183, I'm hoping that fewer components will rely on this class.

          Show
          Chris Douglas added a comment - That could be fun to boostrap. DefaultStringifier uses SerializationFactory which could use DefaultStringifier to find the serializer's metadata. [...] This is not what I'm talking about. The Stringifier interface obviously doesn't require something as general as DefaultStringifier and nobody has argued that a Map<String,String> is wrong. The issue is whether the current patch offers the best approach to render the metadata to the serialization; its superiority to big, blobby stuff is not obvious. By noting that efforts to push non-primitive types into Configuration has a precedent and an interface, I did not intend to advocate for a pluggable meta-serialization layer on top of Configuration. Note that we don't need to filter the entire configuration unless someone iterates over the subset. [...] Returning a Map from Configuration and restricting its range is cleaner and easier to explain. If iteration isn't required, then this approach sounds good to me. If we did need to support iteration, then perhaps we could change Configuration to use treemap, but that might open other cans of worms. Agreed. After seeing MAPREDUCE-1183 , I'm hoping that fewer components will rely on this class.
          Hide
          Doug Cutting added a comment -

          > If iteration isn't required, then this approach sounds good to me.

          Great. I think iteration is not required, so let's pursue this.

          > After seeing MAPREDUCE-1183, I'm hoping that fewer components will rely on this class.

          I don't understand what you're saying here. What do you mean by "this class"? Configuration?

          Show
          Doug Cutting added a comment - > If iteration isn't required, then this approach sounds good to me. Great. I think iteration is not required, so let's pursue this. > After seeing MAPREDUCE-1183 , I'm hoping that fewer components will rely on this class. I don't understand what you're saying here. What do you mean by "this class"? Configuration?
          Hide
          Aaron Kimball added a comment -

          Attaching a patch that uses a view-based Map implementation that doesn't support iteration. I looked through the serializer package and didn't see any uses if size(), entrySet(), or keySet(), so I think this should suffice.

          Show
          Aaron Kimball added a comment - Attaching a patch that uses a view-based Map implementation that doesn't support iteration. I looked through the serializer package and didn't see any uses if size(), entrySet(), or keySet(), so I think this should suffice.
          Hide
          Hadoop QA added a comment -

          +1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12427994/HADOOP-6420.5.patch
          against trunk revision 890588.

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 3 new or modified tests.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 findbugs. The patch does not introduce any new Findbugs warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          +1 core tests. The patch passed core unit tests.

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h1.grid.sp2.yahoo.net/27/testReport/
          Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h1.grid.sp2.yahoo.net/27/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
          Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h1.grid.sp2.yahoo.net/27/artifact/trunk/build/test/checkstyle-errors.html
          Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h1.grid.sp2.yahoo.net/27/console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12427994/HADOOP-6420.5.patch against trunk revision 890588. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h1.grid.sp2.yahoo.net/27/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h1.grid.sp2.yahoo.net/27/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h1.grid.sp2.yahoo.net/27/artifact/trunk/build/test/checkstyle-errors.html Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h1.grid.sp2.yahoo.net/27/console This message is automatically generated.
          Hide
          Steve Loughran added a comment -

          Might be handy to make the ConfigItemMap class protected, so that those people who have subclassed a Configuration can work with them

          Show
          Steve Loughran added a comment - Might be handy to make the ConfigItemMap class protected, so that those people who have subclassed a Configuration can work with them
          Hide
          Aaron Kimball added a comment -

          Good suggestion Steve. Done.

          Show
          Aaron Kimball added a comment - Good suggestion Steve. Done.
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12428101/HADOOP-6420.6.patch
          against trunk revision 890964.

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 3 new or modified tests.

          -1 javadoc. The javadoc tool appears to have generated 1 warning messages.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 findbugs. The patch does not introduce any new Findbugs warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          +1 core tests. The patch passed core unit tests.

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/206/testReport/
          Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/206/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
          Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/206/artifact/trunk/build/test/checkstyle-errors.html
          Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/206/console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12428101/HADOOP-6420.6.patch against trunk revision 890964. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. -1 javadoc. The javadoc tool appears to have generated 1 warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/206/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/206/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/206/artifact/trunk/build/test/checkstyle-errors.html Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/206/console This message is automatically generated.
          Hide
          Aaron Kimball added a comment -

          Fix javadoc warning.

          Show
          Aaron Kimball added a comment - Fix javadoc warning.
          Hide
          Hadoop QA added a comment -

          +1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12428107/HADOOP-6420.7.patch
          against trunk revision 890964.

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 3 new or modified tests.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 findbugs. The patch does not introduce any new Findbugs warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          +1 core tests. The patch passed core unit tests.

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/207/testReport/
          Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/207/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
          Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/207/artifact/trunk/build/test/checkstyle-errors.html
          Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/207/console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12428107/HADOOP-6420.7.patch against trunk revision 890964. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/207/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/207/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/207/artifact/trunk/build/test/checkstyle-errors.html Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/207/console This message is automatically generated.
          Hide
          Aaron Kimball added a comment -

          I realized after working more on MAPREDUCE-1126 that I need the ability to determine if a map is empty or not; when I was using the HashMap-based (deep-copy) getMap(), this was accomplished via Map.size() == 0; but determining the map's size in general requires iteration, which we decided not to support due to the expense.

          Instead I've added a sentinel value that indicates whether the map exists or not. This is set by setMap() and can be read with mapExists(). Since we also support users creating maps using the underlying properties (e.g., conf.set("foo.bar", "a"); conf.set("foo.baz", "b"); conf.getMap("foo")), I've added a declareMap() method that adds the sentinel as well. (so you could write: conf.set("foo.bar", "a"); conf.set("foo.baz", "b"); conf.declareMap("foo"); assertTrue(conf.mapExists("foo")). This works by creating a key named "foo" in the Configuration whose value is "$MAP$".

          This is necessary in MAPREDUCE-1126 to determine whether the user has properly called a metadata-API setMapOutputKeyClass() / setMapOutputKeySchema() method, or whether we should fall back to the deprecated JobConf.getMapOutputKeyClass() / JobConf.getOutputKeyClass() API.

          Show
          Aaron Kimball added a comment - I realized after working more on MAPREDUCE-1126 that I need the ability to determine if a map is empty or not; when I was using the HashMap-based (deep-copy) getMap(), this was accomplished via Map.size() == 0 ; but determining the map's size in general requires iteration, which we decided not to support due to the expense. Instead I've added a sentinel value that indicates whether the map exists or not. This is set by setMap() and can be read with mapExists() . Since we also support users creating maps using the underlying properties (e.g., conf.set("foo.bar", "a"); conf.set("foo.baz", "b"); conf.getMap("foo") ), I've added a declareMap() method that adds the sentinel as well. (so you could write: conf.set("foo.bar", "a"); conf.set("foo.baz", "b"); conf.declareMap("foo"); assertTrue(conf.mapExists("foo") ). This works by creating a key named "foo" in the Configuration whose value is "$MAP$" . This is necessary in MAPREDUCE-1126 to determine whether the user has properly called a metadata-API setMapOutputKeyClass() / setMapOutputKeySchema() method, or whether we should fall back to the deprecated JobConf.getMapOutputKeyClass() / JobConf.getOutputKeyClass() API.
          Hide
          Aaron Kimball added a comment -

          To be more specific; I don't need to know whether the map is empty per se; it is enough to know whether it is defined or not.

          Show
          Aaron Kimball added a comment - To be more specific; I don't need to know whether the map is empty per se; it is enough to know whether it is defined or not.
          Hide
          Hadoop QA added a comment -

          +1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12428116/HADOOP-6420.8.patch
          against trunk revision 890964.

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 3 new or modified tests.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 findbugs. The patch does not introduce any new Findbugs warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          +1 core tests. The patch passed core unit tests.

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/208/testReport/
          Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/208/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
          Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/208/artifact/trunk/build/test/checkstyle-errors.html
          Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/208/console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12428116/HADOOP-6420.8.patch against trunk revision 890964. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/208/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/208/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/208/artifact/trunk/build/test/checkstyle-errors.html Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/208/console This message is automatically generated.
          Hide
          Chris Douglas added a comment -

          What do you mean by "this class"? Configuration?

          Yes.

          we also support users creating maps using the underlying properties (e.g., conf.set("foo.bar", "a"); conf.set("foo.baz", "b"); conf.getMap("foo")), I've added a declareMap() method that adds the sentinel as well.

          This is incoherent. Either the user can set and retrieve string->string maps from Configuration or this is offering an API to Configuration to address a subset of its members behind a preferred interface (i.e. Map<String,String>). In the latter case (A), a Map<String,String> wrapping a Configuration instance admits the ad-hoc "map" creation outlined above. In the former case (B), this should attempt to guarantee that the Map goes in and out of Configuration without being interfered with, excluding this use case.

          Given how general Configuration is, I don't see a way to enforce B invariants without having a blob as the value. If A is the goal- because one wants to add to this sub-map at different stages efficiently, add values via the wrapper interface, or for some other reason- then by definition it creates a sub-map by being interpreted as one, not by declaration.

          The implementation details of MAPREDUCE-1126- particularly those enforcing backwards-compatibility- should not bleed into a general Configuration feature. If the metadata API needs to set a sentinel value in the config, then it should set it.

          On v8:

          1. Two {{ConfigItemMap}}s are only equal if they come from the same Configuration; sharing a prefix is insufficient
          2. What distinguishes lookup from Configuration.this.get(prefix + subKey)?
          3. get/put should check for null, to avoid setting/seeking "prefix.null"
          4. Any particular reason putAll is unsupported?
          5. ConfigItemMap can be a stand-alone or static inner class in conf if (2) is sufficient
          Show
          Chris Douglas added a comment - What do you mean by "this class"? Configuration? Yes. we also support users creating maps using the underlying properties (e.g., conf.set("foo.bar", "a"); conf.set("foo.baz", "b"); conf.getMap("foo")), I've added a declareMap() method that adds the sentinel as well. This is incoherent. Either the user can set and retrieve string->string maps from Configuration or this is offering an API to Configuration to address a subset of its members behind a preferred interface (i.e. Map<String,String>). In the latter case ( A ), a Map<String,String> wrapping a Configuration instance admits the ad-hoc "map" creation outlined above. In the former case ( B ), this should attempt to guarantee that the Map goes in and out of Configuration without being interfered with, excluding this use case. Given how general Configuration is, I don't see a way to enforce B invariants without having a blob as the value. If A is the goal- because one wants to add to this sub-map at different stages efficiently, add values via the wrapper interface, or for some other reason- then by definition it creates a sub-map by being interpreted as one, not by declaration. The implementation details of MAPREDUCE-1126 - particularly those enforcing backwards-compatibility- should not bleed into a general Configuration feature. If the metadata API needs to set a sentinel value in the config, then it should set it. On v8: Two {{ConfigItemMap}}s are only equal if they come from the same Configuration; sharing a prefix is insufficient What distinguishes lookup from Configuration.this.get(prefix + subKey) ? get / put should check for null, to avoid setting/seeking "prefix.null" Any particular reason putAll is unsupported? ConfigItemMap can be a stand-alone or static inner class in conf if (2) is sufficient
          Hide
          Aaron Kimball added a comment -

          Fair point. I think that the semantics of (A) are clearer. I will modify MAPREDUCE-1126 to use external sentinel values.

          As for your other v8 issues

          1) Good call on equals()
          2) Configuration.this.get() will use deprecation-resolution on the provided key. Deprecation-resolution is handled at the map key (prefix) level, not on individual subkeys within the map. So those should not call get().
          3) Yes.
          4) This can be added.
          5) I don't see what you mean. If Configuration.this.get() is used or the current Configuration.this.getProps(), you still need a Configuration.this associated with it, so you can't use a static inner class. You could conceivably hold an explicit reference to the Configuration object, but given that the implicit reference is the whole point of a non-static inner class, I don't see what using a static class buys us.

          Show
          Aaron Kimball added a comment - Fair point. I think that the semantics of (A) are clearer. I will modify MAPREDUCE-1126 to use external sentinel values. As for your other v8 issues 1) Good call on equals() 2) Configuration.this.get() will use deprecation-resolution on the provided key. Deprecation-resolution is handled at the map key (prefix) level, not on individual subkeys within the map. So those should not call get() . 3) Yes. 4) This can be added. 5) I don't see what you mean. If Configuration.this.get() is used or the current Configuration.this.getProps() , you still need a Configuration.this associated with it, so you can't use a static inner class. You could conceivably hold an explicit reference to the Configuration object, but given that the implicit reference is the whole point of a non-static inner class, I don't see what using a static class buys us.
          Hide
          Aaron Kimball added a comment -

          Patch #9 addresses code review concerns

          Show
          Aaron Kimball added a comment - Patch #9 addresses code review concerns
          Hide
          Hadoop QA added a comment -

          +1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12428225/HADOOP-6420.9.patch
          against trunk revision 891132.

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 3 new or modified tests.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 findbugs. The patch does not introduce any new Findbugs warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          +1 core tests. The patch passed core unit tests.

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/211/testReport/
          Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/211/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
          Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/211/artifact/trunk/build/test/checkstyle-errors.html
          Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/211/console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12428225/HADOOP-6420.9.patch against trunk revision 891132. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/211/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/211/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/211/artifact/trunk/build/test/checkstyle-errors.html Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/211/console This message is automatically generated.
          Hide
          Aaron Kimball added a comment -

          Chris,

          Is this ready to go now?

          Show
          Aaron Kimball added a comment - Chris, Is this ready to go now?
          Hide
          Jeff Hammerbacher added a comment -

          Hey Chris,

          Any chance you can take a look at this patch? It's blocking 1126, and there has been a patch available for nearly three weeks.

          Thanks,
          Jeff

          Show
          Jeff Hammerbacher added a comment - Hey Chris, Any chance you can take a look at this patch? It's blocking 1126, and there has been a patch available for nearly three weeks. Thanks, Jeff
          Hide
          Doug Cutting added a comment -

          I wonder if the map implementation might be considerably smaller if you extend AbstractMap, so that only entrySet() need explicitly throw UnsupportedOperationException?

          Show
          Doug Cutting added a comment - I wonder if the map implementation might be considerably smaller if you extend AbstractMap, so that only entrySet() need explicitly throw UnsupportedOperationException?
          Hide
          Aaron Kimball added a comment -

          Good catch. new patch with extends AbstractMap

          Show
          Aaron Kimball added a comment - Good catch. new patch with extends AbstractMap
          Hide
          Hadoop QA added a comment -

          +1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12429588/HADOOP-6420.10.patch
          against trunk revision 896691.

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 3 new or modified tests.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 findbugs. The patch does not introduce any new Findbugs warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          +1 core tests. The patch passed core unit tests.

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/261/testReport/
          Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/261/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
          Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/261/artifact/trunk/build/test/checkstyle-errors.html
          Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/261/console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12429588/HADOOP-6420.10.patch against trunk revision 896691. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/261/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/261/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/261/artifact/trunk/build/test/checkstyle-errors.html Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/261/console This message is automatically generated.
          Hide
          Doug Cutting added a comment -

          +1 This looks good to me. Unless there are objections I'll commit this tomorrow.

          Show
          Doug Cutting added a comment - +1 This looks good to me. Unless there are objections I'll commit this tomorrow.
          Hide
          Chris Douglas added a comment -

          You could conceivably hold an explicit reference to the Configuration object, but given that the implicit reference is the whole point of a non-static inner class, I don't see what using a static class buys us.

          I intended (5) to depend on (2); since the deprecation semantics push for an inner class, the point is moot. The static/inner class is just a matter of taste; if the inner class didn't require access to private members, limiting its visibility to public methods keeps the APIs clean.

          Given its semantics, addMap (implying A) may be more apt than setMap (implying B), but it's debatable and the documentation makes its semantics clear.

          +1

          Show
          Chris Douglas added a comment - You could conceivably hold an explicit reference to the Configuration object, but given that the implicit reference is the whole point of a non-static inner class, I don't see what using a static class buys us. I intended (5) to depend on (2); since the deprecation semantics push for an inner class, the point is moot. The static/inner class is just a matter of taste; if the inner class didn't require access to private members, limiting its visibility to public methods keeps the APIs clean. Given its semantics, addMap (implying A ) may be more apt than setMap (implying B ), but it's debatable and the documentation makes its semantics clear. +1
          Hide
          Chris Douglas added a comment -

          I committed this. Thanks, Aaron!

          Show
          Chris Douglas added a comment - I committed this. Thanks, Aaron!
          Hide
          Hudson added a comment -

          Integrated in Hadoop-Common-trunk-Commit #137 (See http://hudson.zones.apache.org/hudson/job/Hadoop-Common-trunk-Commit/137/)
          . Add functionality permitting subsets of Configuration to be
          interpreted as Map<String,String>. Contributed by Aaron Kimball

          Show
          Hudson added a comment - Integrated in Hadoop-Common-trunk-Commit #137 (See http://hudson.zones.apache.org/hudson/job/Hadoop-Common-trunk-Commit/137/ ) . Add functionality permitting subsets of Configuration to be interpreted as Map<String,String>. Contributed by Aaron Kimball
          Hide
          Hudson added a comment -

          Integrated in Hadoop-Common-trunk #212 (See http://hudson.zones.apache.org/hudson/job/Hadoop-Common-trunk/212/)
          . Add functionality permitting subsets of Configuration to be
          interpreted as Map<String,String>. Contributed by Aaron Kimball

          Show
          Hudson added a comment - Integrated in Hadoop-Common-trunk #212 (See http://hudson.zones.apache.org/hudson/job/Hadoop-Common-trunk/212/ ) . Add functionality permitting subsets of Configuration to be interpreted as Map<String,String>. Contributed by Aaron Kimball

            People

            • Assignee:
              Aaron Kimball
              Reporter:
              Aaron Kimball
            • Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development