Issue Details (XML | Word | Printable)

Key: HADOOP-5708
Type: Improvement Improvement
Status: Closed Closed
Resolution: Invalid
Priority: Minor Minor
Assignee: Unassigned
Reporter: Topher ZiCornell
Votes: 0
Watchers: 5
Operations

If you were logged in you would be able to see more operations.
Hadoop Common

Configuration should provide a way to write only properties that have been set

Created: 20/Apr/09 08:18 PM   Updated: 24/Apr/09 08:48 PM
Return to search
Component/s: conf
Affects Version/s: 0.19.1
Fix Version/s: None

Time Tracking:
Not Specified

File Attachments:
  Size
Text File Licensed for inclusion in ASF works 01_configuration.patch 2009-04-23 05:49 PM Shevek 50 kB
Text File Licensed for inclusion in ASF works 02_configuration.patch 2009-04-24 08:47 PM Shevek 53 kB
Issue Links:
Reference
 

Resolution Date: 21/Apr/09 11:30 PM


 Description  « Hide
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



 All   Comments   Work Log   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
There are no subversion log entries for this issue yet.