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