默认+个性化灵活配置你的系统
项目中经常使用配置文件来配置一些对环境依赖的数据，例如数据库连接、用户名、密码、以及一些域名、端口等等，而往往这些配置文件一般都是跟着项目工程一起提交到svn中，即每个项目组成员同步代码时这些config配置都会同步下来，保持一致，有这么一种场景，每个开发人员在本地运行代码，可能会重新配置一些本地的数据，例如域名、端口，这就需要修改这个配置文件，然后打包运行，这本没有任何问题，不过这也可能是杯具开始的源头，某个开发人员如果一不小心将这个配置文件commit到svn中了，其他开发人员可能更新的时候就会更新到这个开发人员的本地配置，导致之前本来配置好的数据被update下来的数据给覆盖了，系统运行不起来，岂不是杯具。
如何解决这个问题?其实解决思想比较简单，我们希望理想的个性化环境配置数据按照这个过程来处理：如果开发本地没有这个配置数据，那么就使用系统默认配置，否则使用开发本地配置数据覆盖默认配置。
利用maven来说明一下，如果利用maven的filter来完成我们理想化的个性化配置，又不至于上面提到的悲剧发生。
首先，在项目中pom.xml的配置，filters元素以及需要使用配置数据替换的目录。
解释下，filters元素配置属性文件所在的位置，属性文件格式是标准的例如jdbc.username =mysql 的格式，resource下配置需要进行过滤的目录，也就是需要使用属性替换的文件目录，没有filtering元素，默认值是false,这里设置成true,表示这个目录下的文件需要替换。
假设src/main/resources目录下有一个persistence.xml文件，其中有一个配置
当mvn install打包后，这里的${jdbc.username}就会使用mysql进行代替，是否很方便。好，上面提到的文件以及代码都会提交到svn代码库中，任何其他开放人员都可以checkout并打包运行，现在某个开发人员，在本地自己建立了数据库，将数据库名修改成mysqltest,他可以简单修改这里的default.properties文件中的jdbc.username =mysqltest,然后打包运行，当然没问题，当然，他得保证他不会将这个文件提交到代码库中,假设这个开发人员可以保证不提交上去，万一其他开发人员不小心提交了一个别人自己的数据库名上来呢?此时这个开发人员更新代码，要么就是代码冲突，要么就是被覆盖，后果不说了，浪费同志们时间。
另外一个办法就是系统中这份配置文件我们作为默认配置，当需要修改其中某几项配置时，在本地项目外配置一个个人性化的配置，这样也就不会意外提交到svn代码库中影响到别人了…，maven中同样也提供了这样的功能，即profiles。在maven的安装目录下的conf下或者系统用户目录的.m2下，找到settings.xml文件，找到profiles元素，如下配置
配置完成后，再运行一下mvn intall，看下，这里的本地配置mysqltest生效了，如果去掉profile中的属性配置，默认的mysql又生效了。
-----------------------------------------------------------------------------------------------------
总结：
1、系统中的默认值配置一般设置为通用公用测试环境配置，特别是公司内有自己的公用测试环境的情况下，默认值按照公用测试环境值作为默认值，这样，每个人直接checkout代码不需要做本地配置，或者少许配置即可在测试环境下运行。注：默认值一定不要设置为线上的配置，否则可能不小心(比如压力测试时)把线上系统给搞挂了。
2、本地个人性配置修改本地配置文件，不要去动系统默认值。
3、线上环境配置打包需要采用个性化方式重新覆盖默认值，好处在于对于线上数据隔离要求较高的配置数据(例如密码)可以避免其他无关人员看到。
