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-9241) HDFS clients can't construct HdfsConfiguration instances
Date Fri, 16 Oct 2015 14:29:05 GMT

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

Steve Loughran commented on HDFS-9241:
--------------------------------------

One other thing to consider is "would we expect thin clients to ever instantiate this class?".
If so, should it be in that JAR. 

until now, creating it has been the way to force hdfs-site in, just as creating a {{YarnConfiguration()}}
forced that in. After hitting problems with race conditions in UGI init, I now load all of
these on startup. Should this be necessary?

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