[ https://issues.apache.org/jira/browse/HDFS-8939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jakob Homan updated HDFS-8939: ------------------------------ Attachment: HDFS-8939-branch-2.001.patch Match getDefaultPort behavior on trunk. > Test(S)WebHdfsFileContextMainOperations failing on branch-2 > ----------------------------------------------------------- > > Key: HDFS-8939 > URL: https://issues.apache.org/jira/browse/HDFS-8939 > Project: Hadoop HDFS > Issue Type: Bug > Components: webhdfs > Affects Versions: 2.8.0 > Reporter: Jakob Homan > Fix For: 2.8.0 > > Attachments: HDFS-8939-branch-2.001.patch > > > After HDFS-8180, TestWebHdfsFileContextMainOperations and > TestSWebHdfsFileContextMainOperations are failing with runtime NPEs while > instantiating the wrapped WebHDFSFileSystems because {{getDefaultPort}} is > trying to access a conf that was never provided. In the constructor both > both WebHdfs and SWebhdfs the underlying (S)WebHdfsFileSystems are > instantiated in the constructor and never have a chance to have their > {{setConf}} methods called: > {code} SWebHdfs(URI theUri, Configuration conf) > throws IOException, URISyntaxException { > super(theUri, new SWebHdfsFileSystem(), conf, SCHEME, false); > }r{code} > The test passes on trunk because HDFS-5321 removed the call to the > Configuration instance as part of {{getDefaultPort}}. HDFS-5321 was applied > to branch-2 but reverted in HDFS-6632, so there's a bit of a difference in > how branch-2 versus trunk handles default values (branch-2 pulls them from > configs if specified, trunk just returns the hard-coded value from the > constants file). > I've fixed this behave like trunk and return just the hard-coded value, which > causes the test to pass. > There is no WebHdfsFileSystem that takes a Config, which would be another > way to fix this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)