[ https://issues.apache.org/jira/browse/HDFS-9241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14964044#comment-14964044 ]
Colin Patrick McCabe commented on HDFS-9241: -------------------------------------------- bq. I see your point, but I will note that it loses part of the benefit of the whole idea of a leaner client "you miss out all the server-side dependencies" As we commented when the project started, the client is not "thin"-- most of the problematic dependencies like Jackson, Guava, Jetty, Jersey, Netty, Xerces, Protobuf are included in the client anyway. So the client/server split provides no meaningful dependency isolation with or without this change. > 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)