需求分析：

解决根绝环境动态绑定配置参数需求

现有主流解决方案：

1. spring、logback等框架的placeholder替换
   缺点：需要依赖特定框架，且用法不统一。

2. 中心配置服务器
   缺点：

3. 增加系统复杂性，对中心配置服务器的性能和高可用保障。

4. 需要改造应用，对接中心配置服务器。

5. 还是存在依赖中心配置服务器的IP、端口等参数没有解决。

6. Maven Filtering
   缺点：

7. build结束生成二级制包后无法更改参数内容。

8. 缺少参数的验证机制。

AutoConfig特性：

1. 独立使用或做为maven插件使用。
2. 对目标文件而不是源文件配置，支持嵌套目标文件配置。
3. 验证properties机制。 （通过<property>的required属性和子标签<validator>实现）

开发者指南

AutoConfig配置文件的目录结构：

1. war包是 /src/main/webapp/META-INF/autoconf/auto-config.xml
2. jar包是 /src/main/resources/META-INF/autoconf/auto-config.xml
3. 普通目录是/conf/auto-config.xml

描述文件auto-config.xml 定义了property属性占位置（仅仅是配置属性里键值对里的值这部分）和对应的校验规则。

模板文件（记录不同环境需要哪些属性的键值对）的位置

定义完auto-config.xml描述文件以后，就可以创建模板了。模板放在哪里呢？举例说明。
假设在一个典型的WEB应用中，你的auto-config.xml
中包含指定了如下模板：

<?xml version="1.0" encoding="UTF-8"?>
  <config>
    <group> ... </group>
    <script>
      <generate template="WEB-INF/classes/file1.xml" /> 
      <generate template="WEB-INF/classes/file2.xml" />
      <generate template="WEB-INF/file3.xml" />
    </script>
  </config>

那么，你可以把file1.xml
、file2.xml
、file3.xml
放在下面的位置：

Paste_Image.png

AutoConfig的寻找模板的逻辑是：
如果在auto-config.xml所在的目录下发现模板文件，就使用它；(相对目录的起始位置从auto-config.xml所在目录开始)
否则在包的根目录中查找模板文件；如果两处均未找到，则报错。

部署指南