hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mingliang Liu (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HDFS-9241) HDFS clients can't construct HdfsConfiguration instances
Date Wed, 21 Oct 2015 06:25:27 GMT

     [ https://issues.apache.org/jira/browse/HDFS-9241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Mingliang Liu updated HDFS-9241:
--------------------------------
    Attachment: HDFS-9241.001.patch

The v1 patch moves the {{HdfsConfiguration}} class from {{hadoop-hdfs}} to {{hadoop-hdfs-client}}
module so that the current downstream code will not be broken if it uses {{HdfsConfiguration.init()}}
to forcefully load default HDFS resources.

To add deprecated keys in {{HdfsConfiguration}}, some config keys are moved to {{hadoop-hdfs-client}}
module as well.

> HDFS clients can't construct HdfsConfiguration instances
> --------------------------------------------------------
>
>                 Key: HDFS-9241
>                 URL: https://issues.apache.org/jira/browse/HDFS-9241
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: hdfs-client
>            Reporter: Steve Loughran
>            Assignee: Mingliang Liu
>         Attachments: HDFS-9241.000.patch, HDFS-9241.001.patch
>
>
> the changes for the hdfs client classpath make instantiating {{HdfsConfiguration}} from
the client impossible; it only lives server side. This breaks any app which creates one.
> I know people will look at the {{@Private}} tag and say "don't do that then", but it's
worth considering precisely why I, at least, do this: it's the only way to guarantee that
the hdfs-default and hdfs-site resources get on the classpath, including all the security
settings. It's precisely the use case which {{HdfsConfigurationLoader.init();}} offers internally
to the hdfs code.
> What am I meant to do now? 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message