hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-6418) Regression: DFS_NAMENODE_USER_NAME_KEY missing in trunk
Date Wed, 28 May 2014 19:33:02 GMT

    [ 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)

Mime
View raw message