[
https://issues.apache.org/jira/browse/HDFS-9241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14961842#comment-14961842
]
Steve Loughran commented on HDFS-9241:
--------------------------------------
to clarify then
# the thin client doesn't have a backwards compatible way to force load
hdfs-site
# the "two lines of code" proposed as a workaround is in fact package private
# the reason for introducing this change is because there are some deprecated
tags
I don't want to come over all [~aw] here but this isn't justification for
making things incompatible. And while, yes, I can include the hdfs all JAR,
that misses the purpose of the hdfs-client package: to produce a leaner
client-side only package.
We've long hand a problem in HDFS, that whereas Yarn's {{YarnConfiguration}},
and indeed {{JobConfiguration}} have been public with stable string constants
designed for public consumption, the sole set of string constants in HDFS have
been considered private, free to change on a whim. Either we downstream
developers end up importing and something which has a history of being broken
(HDFS-6418) on the grounds that "people downstream should have cut and paste
strings into their source". At least when people use {{DFSConfigKeys}} values,
you can use the IDE to find the load points.
I propose
# accepting that yes, there are deprecated constants in {{DFSConfigKeys}}, but
they are used in client apps
# moving it and the HdfsConfiguration class into hdfs-client
It's not going to add new dependencies, and it will retain compatibility.
> 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)
