[
https://issues.apache.org/jira/browse/HADOOP-8115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13217371#comment-13217371
]
Marc Harris commented on HADOOP-8115:
-------------------------------------
The order of loading wrt. mapred vs. hdfs vs. core is not something that can
easily be made consistent. However default vs. site looks like it should be
fairly straightforward. The full set of files gets re-loaded whenever a
configuration file gets added to the list so it would be straightforward to
make sure that the default ones are loaded first. This could be done based on
the file names, based on whether they are in the jar files or the file system,
or more properly by having the callers of Configuration.addDefaultResource say
whether the resource is a default or not.
> 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
