Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Date: Sat, 22 Aug 2015 01:30:46 +0000 (UTC)
From: "Jakob Homan (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: <JIRA.12858019.1440206986000.136043.1440207046037@Atlassian.JIRA>
In-Reply-To: <JIRA.12858019.1440206986000@Atlassian.JIRA>
References: <JIRA.12858019.1440206986000@Atlassian.JIRA>
 <JIRA.12858019.1440206986016@arcas>
Subject: [jira] [Updated] (HDFS-8939)
 Test(S)WebHdfsFileContextMainOperations failing on branch-2
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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