autoconfig是webx(阿里凯越的web框架)中的一个工具包。在web应用中,有些参数不适合硬编码在代码中,比如:
1、用户名、密码。
2、日常、线上环境使用不同的配置,比如数据库。
其他几种方案:
1、运行时用JVM的参数替换placeholder占位符。
2、中心配置服务器,在运行时刻将所需的参数推送到应用中。
3、maven filtering机制,在资源文件被复制到目标目录的同时,替换其中的placeholders。
AutoConfig机制:
AutoConfig机制是一种类似于maven filtering的build时刻工具。maven filtering在分享工程的时候有一个问题:假设有工程B依赖于工程A,如果使用maven filtering机制,A被build时替换其中的placeholders,然后A被发布到repository中,B就无法再修改A中的配置参数(唯一的方法是获取A的源码并重新build),AutoConfig解决了这个问题(不过这样是不是有了另一个问题?多个工程依赖同一个工程的时候,这个工程中所有的配置项都要在其他的工程中进行配置)。
AutoConfig用法:
1、/META-INF/autoconf目录(如果是普通目录则为/conf)用来存放AutoCOnfig描述文件(auto-config.xml)以及可选模板文件。
2、auto-config.xml用来指导AutoConfig行为的关键描述文件。
auto-confi.xml文件包括以下几部分:
properties用来描述placeholders:<property name="petstore.work" description="应用程序的工作目录" />
name:property名称。
defaultValue:默认值。
description:描述。
required:为true时,如果deployer没有提供必填项的值就会报错。
script指定包含placeholders的模板文件:<generate template="WEB-INF/web.xml" />
template:需要配置的模板名。模板名为相对路径,相对于当前jar/war/ear包的根目录。
destfile:目标问及那,如果不指定则表示目标问及那和模板文件相同。
charset:模板的字符集编码。
outputCharset:目标文件输出字符集编码。
AutoConfig寻找模板的逻辑是:
首先,在auto-config.xml所在的目录下发现模板文件的话,就用它。
然后,如果没有找到就在包的根目录下找,如果还找不到就报错。
AutoConfig替换的过程其实是由Velocity模板引擎来渲染的,因此所有的placeholders必须能够通过Velocity的语法。可以通过maven plugin来执行AutoConfig:
<build>
<plugins>
<plugin>
<groupId>com.alibaba.citrus.tool</groupId>
<artifactId>autoconfig-maven-plugin</artifactId>
<version>${autoconfig-plugin-version}</version>
<configuration>
<!-- 要进行AutoConfig的目标文件,默认为${project.artifact.file}。
<dest>${project.artifact.file}</dest>
-->
<!-- 配置后,是否展开目标文件,默认为false,不展开。
<exploding>true</exploding>
-->
<!-- 展开到指定目录,默认为${project.build.directory}/${project.build.finalName}。
<explodedDirectory>
${project.build.directory}/${project.build.finalName}
</explodedDirectory>
-->
</configuration>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>autoconfig</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
这样在每次执行mvn package或者mvn install时都会激活AutoConfig。