[
https://issues.apache.org/jira/browse/HADOOP-5708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12700978#action_12700978
]
Topher ZiCornell commented on HADOOP-5708:
------------------------------------------
And, just to add: I'm not trying to "fix" anything. I don't think the current
implementation is broken. In fact, I think most of the time it's exactly what
is needed and desired.
I'm only trying to provide an extension that would be useful in certain,
admittedly extreme, situations. I happen to be bumping into a situation in
which this addition would make things much nicer.
. Topher
> Configuration should provide a way to write only properties that have been set
> ------------------------------------------------------------------------------
>
> Key: HADOOP-5708
> URL: https://issues.apache.org/jira/browse/HADOOP-5708
> Project: Hadoop Core
> Issue Type: Improvement
> Components: conf
> Affects Versions: 0.19.1
> Reporter: Topher ZiCornell
> Priority: Minor
>
> The Configuration.write and .writeXml methods always output all properties,
> whether they came from a default source, a loaded resource file, or an
> "overlay" set call. There should be a way to write only the properties that
> were set, leaving out the properties that came from a default source.
> Why? Suppose I build a configuration on a machine that is not associated
> with a grid, write it out to XML, then try to load it on a grid gateway. The
> configuration would contain all of the defaults picked up from my non-grid
> machine, and would completely overwrite all the defaults on that grid.
> I propose to add methods to write out only the overlay values in Object and
> XML formats.
> I see two options for implementing this:
> 1) Either completely new methods could be crafted (writeOverlay(DataOutput)
> and writeOverlayXml(OutputStream), or
> 2) The existing write() and writeXml() methods could be adjusted to take an
> additional parameter indicating whether the full properties or overlay
> properties should be written. (Of course, the existing write() and
> writeXml() methods would remain, defaulting to the current behavior.)
> Option 1 has less impact to existing code. Option 2 is a cleaner
> implementation with less code-duplication involved. I would much prefer to
> do option 2.
> Oh, and in case it's not clear, I'm offering to make this change and submit
> it.
> Thoughts?
> . Topher
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
