这里暂且把XML格式放在一边吧，我们来看看Java使用的最多的.properties配置文件...

今天，看到好几个J2EE的应用发布到服务器上的时候，都要在J2EE Container启动的时候，在启动的脚本上面添加启动的参数：

 -DSystemAConfigFile="XXXXX" -DSystemBConfigFile="YYYYY" -DSystemCConfigFile="ZZZZZ"

这样一来，每每有新的应用需要发布到J2EE Applicaion Server的时候，又要来修改启动脚本，并作停机和重新启动的动作...给生产带来了很大的不便...

反过来看看目前流行的做法，比如说log4j、hibernate等等都有一个很好的解决办法，就是把对应的配置文件（某个.properties的文档），放在应用的classes目录下，相关的程序会自己去读取...

看了一下，其实就是利用ClassLoader.getSystemResourceAsStream()来实现的，因为对于某一个应用，所有Class的装载，都是由一系列存在父子关系的ClassLoader来完成的...通过上面这个方法，会递归查找所需要的properties文件...作了一个代码如下：

package net.csdn.blog.xport;

 import java.io.InputStream;
 import java.util.Properties;

 import org.apache.log4j.LogManager;
 import org.apache.log4j.Logger;

 public class Configure {

   private static final Logger logger = LogManager.getLogger(Configure.class);

   private String propertiesFileName;
   private Properties propertiesTable;

   public Configure() {
     this.loadPropertiesTable();
   }

   public Configure(String propertiesFileName) {
     this.setPropertiesFileName(propertiesFileName);
     this.loadPropertiesTable();
   }

   public String getPropertiesFileName() {
     return this.propertiesFileName;
   }

   public void setPropertiesFileName(String propertiesFileName) {
     this.propertiesFileName = propertiesFileName;
   }

   private void loadPropertiesTable() {
     propertiesTable = new Properties();
     if (this.propertiesFileName != null && this.propertiesFileName != "") {
       try {
        /*
         * 2005/11/14, 同事发现了此处存在Bug，只能在Console模式下运行，如果是在Web方式下
         * 存在Bug...原因是此处使用了ClassLoader类别读取Resource，丢失了层级关系！
          * InputStream in =
          *   ClassLoader.getSystemResourceAsStream(this.propertiesFileName);
         * propertiesTable.load(in);
        */
        ClassLoader classLoader = Configure.class.getClassLoader();
        URL resUrl = classLoader.getResource(this.propertiesFileName);
        /*
         * 虽然拿到了URL, 不好用new FileInputStream(URL.toString())来操作，因为在Windows
         * 和*NIX上面，对file:///协议的表示是不兼容的。java.net.URL会把Windows上面的文件
         * 地址解释为file:/D:/xxx/，这样就错了，正确的应该是file:///D:/xxx !
         *
         * 所以，既然有了URL对象，就可以直接openStream了！
         */
        InputStream in = resUrl.openStream();
        propertiesTable.load(in);
       }
       catch (Exception ex) {
         logger.debug(ex.getMessage(), ex);
         logger.info("can not load properties file:" + this.propertiesFileName);
       }
     }
   }

   public String getProperty(String propertyName) {
     return this.propertiesTable.getProperty(propertyName);
   }

 }

这样，就可以直接修改.properties文件，就可以生效了，不用重开服务器！而且，多个应用之间的配置都是隔离开的，每个配置文件都是随着自己所在的WAR绑定的！对 one AP Server <--> multi Applications 再好不过了！

自己给这个起了个名字，叫做“自适应配置文件读取”！

# java # log4j
Logo
向您推荐>>Eolink开发者社区

权威｜前沿｜技术｜干货｜国内首个API全生命周期开发者社区

更多推荐

ELK实现containerd的容器日志采集展示【基于logging的全栈监测】

企业级ELK Stack构建介绍

avatar 云原生

深入理解 Mocha 测试框架：从零实现一个 Mocha

前言什么是自动化测试自动化测试在很多团队中都是Devops环节中很难执行起来的一个环节，主要原因在于测试代码的编写工作很难抽象，99%的场景都需要和业务强绑定，而且写测试代码的编写工作量往往比编写实际业务代码的工作量更多。在一些很多业务场景中投入产出比很低，适合写自动化测试的应该是那些中长期业务以及一些诸如组件一样的基础库。自动化测试是个比较大的概念，其中分类也比较多，比如单元测试，端对端测试，集

avatar 云原生

(20200916 Solved)docker-compose up创建容器自动退出

问题描述如题，创建容器后自动退出了。并且docker start container无效解决方案原因是缺失了控制终端的配置，需要在docker-compose.yml中增加tty:true ，有时候这样也不行，需要再增加一个command:/bin/bash，命令不一定是这个，需要是一个不会退出的命令，然后用-d后台启动容器。Referencesdocker-compose启动容器后自动退出...

avatar 云原生