accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ctubbsii <...@git.apache.org>
Subject [GitHub] accumulo pull request #236: ACCUMULO-4614 AccumuloClassLoader should load ac...
Date Tue, 28 Mar 2017 21:41:27 GMT
Github user ctubbsii commented on a diff in the pull request:

    https://github.com/apache/accumulo/pull/236#discussion_r108544154
  
    --- Diff: start/src/main/java/org/apache/accumulo/start/classloader/AccumuloClassLoader.java
---
    @@ -44,21 +44,21 @@
     
     public class AccumuloClassLoader {
     
    -  public static final String CLASSPATH_PROPERTY_NAME = "general.classpaths";
    +  public static final String GENERAL_CLASSPATHS = "general.classpaths";
       public static final String MAVEN_PROJECT_BASEDIR_PROPERTY_NAME = "general.maven.project.basedir";
       public static final String DEFAULT_MAVEN_PROJECT_BASEDIR_VALUE = "";
     
    -  private static String SITE_CONF;
    +  private static URL accumuloConfigUrl;
       private static URLClassLoader classloader;
       private static final Logger log = LoggerFactory.getLogger(AccumuloClassLoader.class);
     
       static {
    -    String configFile = System.getProperty("org.apache.accumulo.config.file", "accumulo-site.xml");
    -    if (System.getenv("ACCUMULO_CONF_DIR") != null) {
    -      // accumulo conf dir should be set
    -      SITE_CONF = System.getenv("ACCUMULO_CONF_DIR") + "/" + configFile;
    +    String configFilename = System.getProperty("org.apache.accumulo.config.file", "accumulo-site.xml");
    +    accumuloConfigUrl = AccumuloClassLoader.class.getClassLoader().getResource(configFilename);
    +    if (accumuloConfigUrl == null) {
    +      log.warn("Failed to load Accumulo configuration '{}' from classpath", configFilename);
    --- End diff --
    
    > Any reason to not make it look like a URI and only accept "file://"?
    
    There's not much difference between a File URI and other registered URI schemes. Limiting
to just file might be slightly easier if we want to just parse the string ourselves in a quick-and-dirty
way, rather than use the robust built-in support for URIs. I strongly recommend looking at
what log4j2 does first, before implementing any URI scheme support. The ConfigurationFactory,
NetUtils, and ConfigurationSource classes are particularly insightful about what it takes
to properly parse URI schemes in a robust and consistent way.
    
    I don't understand why the desire to pursue this at all, though. What additional feature
would this actually get you? Any file which can be specified with a file URI scheme could
be supported by referring to the same file on the classpath instead. What am I missing that
makes the URI scheme so appealing?


---
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.
---

Mime
View raw message