（二）关于代码中的配置

上一篇中说到

目前的设计是，基本上除了定时器设置的变动，有可能会修改app-scheduling.xml和spring-servlet.xml文件外，其他的配置都在这个config.properties文件中了

这一篇就来说说这块是怎么做的，看config.properties文件。

1.关于logback的配置。

以前就写了这块的实现，参考这里。主要就是logback的配置没怎么变化，最多就是因为日志的名称不同和日志级别，修改config.properties。

2.关于配置文件的想法。

因为项目部署了很多个tomcat节点，有开发环境、测试环境、生产环境的区别，而生产环境又利用nginx做了不同模块的区分，部分服务的配置稍微有点改动，这时候在部署上线的时候很麻烦，经常要改动配置文件，刚好项目的其他模块，有别人用python做的，这个模块，有个配置文件config.py，里面就利用字典数组的形式来写配置，指定当前环境，就可以读取到对应的配置，于是脑洞大开，是否也可以做类似的配置。

于是在配置文件里加了一个参数curEnv表示当前环境，值设置为.dev或.test或.pro，对于通用的配置，不加后缀，专用的配置就加上对应的配置。比如一个配置apihost=1.2.3.4，因为项目大部分是在生产用，为了便于部署，我把测试环境的配置加上后缀apihost.test=5.6.7.8，默认curEnv=，没有值。这里需要看全局常量类Constants.java

//系统配置文件
private static PropertiesConfiguration config;
private static String curEnv = "";

static{
try {
config = new PropertiesConfiguration();
config.setEncoding("UTF-8");
config.load("config.properties");
config.setReloadingStrategy(new FileChangedReloadingStrategy());
curEnv = config.getString("curEnv");
} catch (ConfigurationException e) {
logger.error("找不到配置文件", e);
}
}

private static String getString(String key) {
if(config.containsKey(key + curEnv)) {
return config.getString(key + curEnv);
}
return config.getString(key);
}

public static String getTestStr() {
return getString("test.str");
}

这里，又有另外一个东西可以说，就是PropertiesConfiguration，这里用到commons-configuration，之所以用到这块，是为了让部分配置即时生效。以前用普通的properties，正常读取文件是没问题，但是当遇到部分参数需要即时生效的时候，就需要重启tomcat，有时候又不允许随便重启，就要到凌晨去重启，很麻烦，找到这个就可以实现立即生效。在配置文件config.properties里面有中文，所以先设置默认用UTF-8来读取文件。之后设置加载策略config.setReloadingStrategy(new FileChangedReloadingStrategy());就是文件改变的时候重新加载。

对于需要即时生效的常量，比如这个test.str，采取这种写法是可以实现我们的效果的，如果写成public static String TESTSTR = getString("test.str");是没用的，个人是这么想的，这个静态变量初始化之后，指向的就是最早使用的值，之后文件的改变，不会触发新的读取。而用方法的形式，每次触发的是getString这个方法，这个方法因为PropertiesConfiguration的管理会读取新值。

这个getString方法针对环境变量curEnv改造了一下，含有当前环境包含的配置，就返回，没有就返回默认的。

在这么做了之后，比如我生产环境就不设置了，就用默认的空，在开发环境就用.dev，在测试环境就用.test。基本上除了数据库的配置是在 applicationContext.xml 不好这么加后缀做区分，其他的都可以了。一般数据库的配置，我按照几个环境，就写几个块在config.properties，不用的时候用#注释。

再后来，部署不用自己做了，但是要打包给负责部署的人，每次都修改配置文件也是麻烦，所以就这么做，比如有3个环境，3套配置，就写3个config.properties，就是命名不一样，配置内容有点不一样，因为一般都在开发环境，所以开发环境的配置文件就命名为config.properties，测试的配置文件命名为config.test.properties，生产的命名为config.pro.properties，在打包的时候，删掉去他无用的配置，把测试或生产的配置文件重命名为config.properties，就可以了。

关于代码中的配置就讲完了。