[
https://issues.apache.org/jira/browse/HADOOP-8115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13217363#comment-13217363
]
Allen Wittenauer commented on HADOOP-8115:
------------------------------------------
Never leave the *-default.xml files in conf/ in modern versions of Hadoop. Bad
Things(tm) always seem to happen.
Lately I've been debating actually just having blank versions of hdfs-site.xml
and mapred-site.xml and merging everything back into core-site.xml like the
olden days. It isn't of much practical use to have different versions of these
files. Plus as we look towards doing an (internal) rewrite of the startup
scripts to autogen the config information, it removes the decision making
around which file is supposed to get which config.
> configuration entry in core-site.xml gets silently ignored
> ----------------------------------------------------------
>
> Key: HADOOP-8115
> URL: https://issues.apache.org/jira/browse/HADOOP-8115
> Project: Hadoop Common
> Issue Type: Bug
> Environment: v 0.20.203.0
> Standard tar release (i.e. not Cloudera or anything)
> Ubuntu
> Reporter: Marc Harris
>
> The order of loading configuration files (and thus the order of priority from
> least to most) seems to be as follows:
> core-default.xml, core-site.xml, hdfs-default.xml, hdfs-site.xml.
> This means that a configuration parameter that is set in hdfs-default.xml
> will override that value set in core-site.xml.
> Either
> (1) Parameters should be able to go in any site.xml file, and override any
> default.xml, even if they don't "match", or
> (2) Putting a parameter in the "wrong" site.xml file should be considered an
> error, and result in at the very least a warning.
> What in fact happens is that the parameter is silently ignored, which is the
> worst combination.
> I my opinion, it is counter-intuitive that a value in a site.xml file should
> be overridden by a value in a default.xml file, so I would choose option (1).
> The particular example here was dfs.http.address, by the way.
> I marked this as major rather than minor since it was not at all obvious what
> the problem (and therefore the workaround was) and eventually required
> attaching to a running production service with a debugger to find out why the
> parameter I was setting was being ignored.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
