Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Date: Wed, 28 May 2014 19:33:02 +0000 (UTC)
From: "Steve Loughran (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: <JIRA.12714813.1400260887846.33440.1401305582451@arcas>
In-Reply-To: <JIRA.12714813.1400260887846@arcas>
References: <JIRA.12714813.1400260887846@arcas>
Subject: [jira] [Commented] (HDFS-6418) Regression:
 DFS_NAMENODE_USER_NAME_KEY missing in trunk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Steve Loughran commented on HDFS-6418:
--------------------------------------

-there's no other place in the hdfs codebase that defines the properties for hdfs as constant strings...anyone who doesn't want to cut and paste values is going to link to this. 

Which is preferable?
# people cut and pasting strings like {"dfs.replication"}
# people importing constants defined in the hadoop source, as is done via {{YarnConfiguration}} and {{CommonConfigurationKeysPublic}}?

I may have been unusual in that I tried to use the in-source constants. And I may have (unintentionally) used them despite them being annotated private -but when you do YARN code you end up treating that as a mild hint anyway. 

Options
# do nothing, I fix my code to inline the constant in my own constants class. I repeat this for any other imports in my code, as I can no longer be confident that they will remain there. Anyone else who uses the constant finds their code breaks. 
# Add a deprecated definition of the old name, using the new name as its reference. 
# action #2, then extract a stable set of constants into a HDFSPublicKeys class for others to use, make this a superclass of the private keys, and encourage people to use these constants in future. 

Now -how are static strings imported into other classes in the compiler? Copied or linked? If copied, code that imports the old definitions will not fail at runtime -only when precompiled. Which would reduce the damage somewhat

> Regression: DFS_NAMENODE_USER_NAME_KEY missing in trunk
> -------------------------------------------------------
>
>                 Key: HDFS-6418
>                 URL: https://issues.apache.org/jira/browse/HDFS-6418
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: hdfs-client
>    Affects Versions: 3.0.0, 2.5.0
>            Reporter: Steve Loughran
>
> Code i have that compiles against HADOOP 2.4 doesn't build against trunk as someone took away {{DFSConfigKeys.DFS_NAMENODE_USER_NAME_KEY}} -apparently in HDFS-6181.
> I know the name was obsolete, but anyone who has compiled code using that reference -rather than cutting and pasting in the string- is going to find their code doesn't work.
> More subtly: that will lead to a link exception trying to run that code on a 2.5+  cluster.
> This is a regression: the old names need to go back in, even if they refer to the new names and are marked as deprecated


--
This message was sent by Atlassian JIRA
(v6.2#6252)