drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From paul-rogers <...@git.apache.org>
Subject [GitHub] drill pull request #796: DRILL-5365: DrillFileSystem setConf in constructor....
Date Sun, 26 Mar 2017 01:15:34 GMT
Github user paul-rogers commented on a diff in the pull request:

    --- Diff: exec/java-exec/src/main/java/org/apache/drill/exec/store/dfs/DrillFileSystem.java
    @@ -89,22 +89,36 @@ public DrillFileSystem(Configuration fsConf) throws IOException {
       public DrillFileSystem(Configuration fsConf, OperatorStats operatorStats) throws IOException
    -    this.underlyingFs = FileSystem.get(fsConf);
    +    this(fsConf, URI.create(fsConf.getRaw(FS_DEFAULT_NAME_KEY)), operatorStats);
    --- End diff --
    Actually, why do we need to do this step? The original code seems to do the right thing:
    class FileSystem ...
      public static FileSystem get(Configuration conf) throws IOException {
        return get(getDefaultUri(conf), conf);
      public static URI getDefaultUri(Configuration conf) {
        return URI.create(fixName(conf.get(FS_DEFAULT_NAME_KEY, DEFAULT_FS)));
    That is, the original code gets the file system using the URI stored in the config. Standard
practice is that the caller must have set the file system property: that is how we tell a
"file:///" system from an HDFS system, etc.
    So, isn't the problem here with the caller?

If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.

View raw message