[jira] [Commented] (HADOOP-8115) configuration entry in core-site.xml gets silently ignored

["Globar (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HADOOP-8115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14046715#comment-14046715 ] 

Globar commented on HADOOP-8115:
--------------------------------

Why are we using the static blocks to load these resources. Shouldn't the configuration classes constructor explicitly load all of the config files: core, hdfs, mapred, etc? 

> 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 was sent by Atlassian JIRA
(v6.2#6252)