第 13 章 AutoConfig工具使用指南
在一個應用中，我們總是會遇到一些參數，例如：
-
數據庫服務器IP地址、端口、用戶名；
-
用來保存上傳資料的目錄。
-
一些參數，諸如是否打開cache、加密所用的密鑰名稱等等。
這些參數有一個共性，那就是：它們和應用的邏輯無關，只和當前環境、當前系統用戶相關。以下場景很常見：
-
在開發、測試、發布階段，使用不同的數據庫服務器；
-
在開發階段，使用Windows的A開發者將用戶上傳的文件存放在
d:\my_upload目錄中，而使用Linux的B開發者將同樣的文件存放在/home/myname/my_upload目錄中。 -
在開發階段設置
cache=off，在生產環境中設置cache=on。
很明顯，這些參數不適合被“硬編碼”在配置文件或代碼中。因為每一個從源碼庫中取得它們的人，都有可能需要修改它們，使之與自己的環境相匹配。
很多框架支持在運行時刻替換配置文件中的placeholder占位符。例如， Webx/Spring就有這個功能。
例 13.1. 在Webx中定義placeholders
<services:property-placeholder />
<services:webx-configuration>
<services:productionMode>${productionMode:true}</services:productionMode>
</services:webx-configuration>
在上面這個例子中，你可以在啟動應用時，加上JVM參數：“-DproductionMode=false|true”來告訴系統用哪一種模式來工作。如果不指定，則取默認值“true”。
運行時替換placeholder是一種非常實用的技術，它有如下優缺點：
表 13.1. 運行時替換placeholders的優缺點
| 優點 | 缺點 |
|---|---|
|
|
這也是一種運行時技術。它可以在運行時刻，將應用所需的參數推送到應用中。
它有如下優缺點：
Maven提供了一種過濾機制，可以在資源文件被復制到目標目錄的同時，替換其中的placeholders。
例 13.2. 配置Maven Filtering機制
假設你的項目目錄結構如下：
web-project
│ pom.xml
│
└─src
└─main
├─java
├─resources
└─webapp
└─WEB-INF
web.xml
在pom.xml中這樣寫：
<build>
<filters>
<filter>${user.home}/antx.properties</filter> 
</filters>
<resources>
<resource>
<directory>src/main/resources</directory> 
<includes> <include>**.xml</include> </includes> <filtering>true</filtering> </resource> <resource> <directory>src/main/resources</directory> <excludes> <exclude>**.xml</exclude> </excludes> </resource> </resources> <plugins> <plugin> <artifactId>maven-war-plugin</artifactId> <configuration> <webResources> <resource> <directory>src/main/webapp</directory> 
<includes> <include>WEB-INF/**.xml</include> </includes> <filtering>true</filtering> </resource> <resource> <directory>src/main/webapp</directory> <excludes> <include>WEB-INF/**.xml</include> </excludes> </resource> </webResources> </configuration> </plugin> </plugins> </build>
這段pom定義告訴maven：
|
|
用指定的properties文件（ |
|
|
過濾 |
|
|
過濾 |
如果上述xml文件中，包含“${xxx.yyy.zzz}”這樣的placeholders，將被替換成properties文件中的相應值。
和運行時替換placeholders方案相比，Maven Filtering是一個build時進行的過程。它的優缺點是：
表 13.3. Maven Filtering機制的優缺點
| 優點 | 缺點 |
|---|---|
|
|
AutoConfig是一種類似於Maven Filtering的build時刻的工具。這意味着該機制與應用所采用的技術、框架完全無關，對應用完全透明，具有良好的通用性。同時，AutoConfig與運行時的配置技術並不沖突。它可以和運行時替換的placeholders以及中心配置服務器完美並存，互為補充。
AutoConfig書寫placeholder的方法和Maven Filtering機制完全相同。換言之，Maven Filtering的配置文件模板（前例中的/WEB-INF/**.xml）可以不加修改地用在AutoConfig中。
然而，autoconfig成功克服了Maven Filtering的主要問題。
表 13.4. Maven Filtering和AutoConfig的比較
| 問題 | Maven Filtering | AutoConfig |
|---|---|---|
| 如何修改配置文件的參數？ | Maven Filtering必須獲得源碼並重新build； | 而AutoConfig不需要提取源碼，也不需要重新build，即可改變目標文件中所有配置文件中placeholders的值。 |
| 如何確保placeholder替換的正確性？ | Maven Filtering不能驗證placeholder值的缺失和錯誤； | 但AutoConfig可以對placeholder及其值進行檢查。 |
接下來，我們將將詳細介紹AutoConfig的使用方法。
很多人會把AutoConfig看作Maven Filtering機制的簡單替代品。事實上，這兩者的設計初衷有很大的區別。
為了把事情說清楚，我們必須要定義兩種角色：開發者（Developer）和部署者（Deployer）。
表 13.5. 角色和職責
| 角色名稱 | 職責 |
|---|---|
| 開發者 |
|
| 部署者 |
|
例如，一個寵物店（petstore）的WEB應用中需要指定一個用來上傳文件的目錄。於是，
表 13.6. Petstore應用中的角色和職責
| 開發者 | 部署者 |
|---|---|
| 開發者定義了一個property： 限定條件為：“合法的文件系統的目錄名”。 |
部署者取得petstore的二進制發布包，通過AutoConfig了解到，應用需要一個名為 部署者便指定一個目錄給petstore，該目錄名的具體值可能因不同的系統而異。 AutoConfig會檢驗該值是否符合限定條件（是否為合法目錄名），如果檢驗通過，就生成配置文件，並將其中的 |
需要注意的是，一個“物理人”所對應的“角色”不是一成不變的。例如：某“開發者”需要試運行應用，此時，他就變成“部署者”。
假設現在有兩個team要互相合作，team A的開發者創建了project A，而team B的開發者創建了project B。假定project B依賴於project A。如果我們利用maven這樣的build工具，那么最顯而易見的合作方案是這樣的：
-
Team A發布一個project A的版本到maven repository中。
-
Team B從maven repository中取得project A的二進制目標文件。
這種方案有很多好處，
-
每個team都可以獨立控制自己發布版本的節奏；
-
Team之間的關系較松散，唯一的關系紐帶就是maven repository。
-
Team之間不需要共享源碼。
然而，假如project A中有一些配置文件中的placeholders需要被替換，如果使用Maven Filtering機制，就會出現問題。因為Maven Filtering只能在project A被build時替換其中的placeholders，一旦project A被發布到repository中，team B的人將無法修改任何project A中的配置參數。除非team B的人取得project A的源碼，並重新build。這將帶來很大的負擔。
AutoConfig解決了這個問題。因為當team B的人從maven repository中取得project A的二進制包時，仍然有機會修改其配置文件里的placeholders。Team B的人甚至不需要了解project A里配置文件的任何細節，AutoConfig會自動發現所有的properties定義，並提示編輯。
部署應用的人（即部署者、deployer）也從中受益。因為deployer不再需要親手去build源代碼，而是從maven repository中取得二進制目標文件即可。
從這個意義上講，AutoConfig不應當被看成是一個build時的簡單配置工具，而是一個“軟件安裝工具”。如同我們安裝一個Windows軟件 —— 我們當然不需要從源碼開始build它們，而是執行其安裝程序，設定一些參數諸如安裝目錄、文檔目錄、可選項等。安裝程序就會自動把軟件設置好，確保軟件可正確運行於當前的Windows環境中。
為了滿足前面所說的目的，我們將AutoConfig設計成下面的樣子：
和Maven Filtering不同的是，AutoConfig是針對目標文件的配置工具。因此AutoConfig關心的目錄結構是目標文件的目錄結構。不同的build工具，創建同一目標目錄結構所需要的源文件的目錄結構會各有不同。本文僅以maven標准目錄結構為例，來說明源文件的目錄結構編排。
這里所說的war包，可以是一個以zip方式打包的文件，也可以是一個展開的目錄。下面以maven標准目錄為例，說明項目源文件和目標文件的目錄結構的對比：
例 13.3. WAR包的源文件和目標文件目錄結構
war-project（源目錄結構） -> war-project.war（目標目錄結構）
│ pom.xml
│
└─src
└─main
├─java
├─resources -> /WEB-INF/classes
│ file1.xml file1.xml
│ file2.xml file2.xml
│
└─webapp -> /
├─META-INF -> /META-INF │ └─autoconf -> /META-INF/autoconf │ auto-config.xml auto-config.xml │ └─WEB-INF -> /WEB-INF web.xml web.xml file3.xml file3.xml
|
|
|
|
|
|
創建war包的AutoConfig機制，關鍵在於創建war目標文件中的/META-INF/autoconf/auto-config.xml描述文件。該描述文件對應的maven項目源文件為：/src/main/webapp/META-INF/autoconf/auto-config.xml。
這里所說的jar包，可以是一個以zip方式打包的文件，也可以是一個展開的目錄。下面以maven標准目錄為例，說明項目源文件和目標文件的目錄結構的對比：
例 13.4. JAR包的源文件和目標文件目錄結構
jar-project（源目錄結構） -> jar-project.jar（目標目錄結構）
│ pom.xml
│
└─src
└─main
├─java
└─resources -> /
│ file1.xml file1.xml
│ file2.xml file2.xml
│
└─META-INF -> /META-INF └─autoconf -> /META-INF/autoconf auto-config.xml auto-config.xml
|
|
|
|
|
|
創建jar包的AutoConfig機制，關鍵在於創建jar目標文件中的/META-INF/autoconf/auto-config.xml描述文件。該描述文件對應的maven項目源文件為：/src/main/resources/META-INF/autoconf/auto-config.xml。
AutoConfig系統的核心就是auto-config.xml描述文件。該描述文件中包含兩部分內容：
-
定義properties：properties的名稱、描述、默認值、約束條件等信息；
-
指定包含placeholders的模板文件。
下面是auto-config.xml文件的樣子：（以petstore應用為例）
例 13.6. AutoConfig描述文件示例
<?xml version="1.0" encoding="UTF-8"?>
<config>
<group>
<property name="petstore.work" description="應用程序的工作目錄" /> <property name="petstore.loggingRoot" defaultValue="${petstore.work}/logs" description="日志文件目錄" /> <property name="petstore.upload" defaultValue="${petstore.work}/upload" description="上傳文件的目錄" /> <property name="petstore.loggingLevel" defaultValue="warn" description="日志文件級別"> 
<validator name="choice" choice="trace, debug, info, warn, error" /> 
</property> </group> <script> <generate template="WEB-INF/web.xml" /> 
<generate template="WEB-INF/common/resources.xml" /> </script> </config>
|
|
定義properties |
|
|
定義property的驗證規則（可選） |
|
|
生成配置文件的指令。 |
定義一個property的完整格式如下：
例 13.7. 定義一個property
<property
name="..." [defaultValue="..."] [description="..."] [required="true|false"] > <validator name="..." /> <validator name="..." /> ... </property>
可用的property參數包括：
目前，有以下幾種驗證器：
表 13.9. 可用的property驗證規則
| 驗證規則 | 說明 |
|---|---|
<validator name="boolean" /> |
Property值必須為 |
<validator name="choice" choice="trace, debug, info, warn, error" /> |
Property值必須為choice所定義的值之一。 |
<validator name="email" /> |
Property值必須為合法的email格式。 |
<validator name="fileExist" [file="WEB-INF/web.xml"] /> |
Property值必須為某個存在的文件或目錄。 如果指定了file，那就意味着property值所指的目錄下，必須存在file所指的文件或子目錄。 |
<validator name="hostExist" /> |
Property值必須為合法的IP地址，或者可以解析得到的域名。 |
<validator name="keyword" /> |
Property值必須為字母、數字、下划線的組合。 |
<validator name="number" /> |
Property值必須為數字的組合。 |
<validator name="regexp" regexp="..." [mode="exact|prefix|contain"] /> |
Property值必須符合regexp所指的正則表達式。 其中，mode為匹配的方法：
如未指定mode，默認mode為contain。 |
<validator name="url" [checkHostExist="false"] [protocols="http, https"] [endsWithSlash="true"] /> |
Property值必須是合法URL。 假如指定了 假如指定了protocols，那么URL的協議必須為其中之一； 假如指定了 |
描述文件中，每個<generate>標簽指定了一個包含placeholders的配置文件模板，具體格式為：
下面是參數的說明：
定義完auto-config.xml描述文件以后，就可以創建模板了。模板放在哪里呢？舉例說明。
例 13.9. 模板文件的位置
假設在一個典型的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放在下面的位置：
war-project（源目錄結構） -> war-project.war（目標目錄結構）
│ pom.xml
│
└─src
└─main
├─java
├─resources -> /WEB-INF/classes │ file1.xml file1.xml - 建議放在這里 │ file2.xml file2.xml - 建議放在這里 │ └─webapp ├─META-INF │ └─autoconf │ │ auto-config.xml │ │ │ └─WEB-INF -> /WEB-INF │ │ file3.xml file3.xml - 也可以放在這里 │ │ │ └─classes -> /WEB-INF/classes │ file1.xml file1.xml - 也可以放在這里 │ file2.xml file2.xml - 也可以放在這里 │ └─WEB-INF -> /WEB-INF file3.xml file3.xml - 建議放在這里
AutoConfig的尋找模板的邏輯是：
-
如果在
auto-config.xml所在的目錄下發現模板文件，就使用它； -
否則在包的根目錄中查找模板文件；如果兩處均未找到，則報錯。
書寫模板是很簡單的事，你只要：
-
把需要配置的點替換成placeholder：“
${property.name}”。當然，你得確保property.name被定義在auto-config.xml中。 -
假如模板中包含不希望被替換的運行時的placeholder“
${...}”，需要更改成“${D}{...}” 。
例 13.10. 模板示例
...
<context-param>
<param-name>loggingRoot</param-name>
<param-value>${petstore.loggingRoot}</param-value>
</context-param>
<context-param>
<param-name>loggingLevel</param-name>
<param-value>${petstore.loggingLevel}</param-value> </context-param> ... ${D}{runtime.placeholder}
此外，AutoConfig模板其實是由Velocity模板引擎來渲染的。因此，所有的placeholder必須能夠通過velocity的語法。
部署者有兩種方法可以使用AutoConfig：
-
在命令行上直接運行。
-
在maven中調用AutoConfig plugin。
AutoConfig提供了Windows以及Unix-like（Linux、Mac OS等）等平台上均可使用的native可執行程序。可執行程序文件被發布在Maven repository中。
如果你已經配置好了maven，那么可以讓maven來幫你下載目標文件。
例 13.12. 讓maven幫忙下載AutoConfig可執行文件
請創建一個臨時文件：pom.xml。
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <parent> <groupId>com.alibaba.citrus.tool</groupId> <artifactId>antx-parent</artifactId> <version>1.2</version> </parent> <modelVersion>4.0.0</modelVersion> <artifactId>temp</artifactId> </project>
|
|
文件中的parent pom的版本號（1.2）決定了你要取得的AutoConfig的版本號。 |
然后在命令行上執行如下命令：
mvn dependency:copy
這樣就取得了兩個文件：
-
autoconfig-1.2.tgz -
autoexpand-1.2.tgz- AutoExpand是另一個小工具。它是用來展開war、jar、ear包的。關於AutoExpand的詳情，請見第 14 章 AutoExpand工具使用指南。
你也可以直接去maven repository中手工下載以上兩個包：
取得壓縮包以后，可以用下面的命令來展開並安裝工具。
取得可執行文件以后，就可以試用一下：在命令行上輸入autoconfig。不帶參數的autoconfig命令會顯示出如下幫助信息。
例 13.13. AutoConfig的幫助信息
$ autoconfig
Detected system charset encoding: UTF-8
If your can't read the following text, specify correct one like this:
autoconfig -c mycharset
使用方法：autoconfig [可選參數] [目錄名|包文件名]
可選參數：
-c,--charset 輸入/輸出編碼字符集
-d,--include-descriptors
包含哪些配置描述文件，例如：conf/auto-config.xml，可使用*、**、?通配符，如有多項，用逗號分隔
-D,--exclude-descriptors 排除哪些配置描述文件，可使用*、**、?通配符，如有多項，用逗號分隔
-g,--gui 圖形用戶界面（交互模式）
-h,--help 顯示幫助信息
-i,--interactive 交互模式：auto|on|off，默認為auto，無參數表示on
-I,--non-interactive 非交互模式，相當於--interactive=off
-n,--shared-props-name 共享的屬性文件的名稱
-o,--output 輸出文件名或目錄名
-P,--exclude-packages 排除哪些打包文件，可使用*、**、?通配符，如有多項，用逗號分隔
-p,--include-packages
包含哪些打包文件，例如：target/*.war，可使用*、**、?通配符，如有多項，用逗號分隔
-s,--shared-props 共享的屬性文件URL列表，以逗號分隔
-T,--type 文件類型，例如：war, jar, ear等
-t,--text 文本用戶界面（交互模式）
-u,--userprop 用戶屬性文件
-v,--verbose 顯示更多信息
總耗費時間：546毫秒
最簡單的AutoConfig命令如下：
無論petstore.war是一個zip包還是目錄，AutoConfig都會正確地生成其中的配置文件。
AutoConfig也可以通過maven plugin來執行。
這種方式使用方式，方便了開發者試運行並測試應用程序。開發者可以在build項目的同時，把AutoConfig也配置好。然而對於非開發的應用測試人員、發布應用的系統管理員來說，最好的方法是使用獨立可執行的AutoConfig來配置應用的二進制目標文件。
為了使用maven插件，你需要修改項目的pom.xml來設定它。請注意，一般來說，不要在parent pom.xml中設定AutoConfig，因為這個設置會作用在每個子項目上，導致不必要的AutoConfig執行。只在生成最終目標文件的子項目pom.xml中設定AutoConfig就可以了。例如，對於一個web項目，你可以在生成war包的子項目上設置AutoConfig plugin。
例 13.15. 在pom.xml中設定AutoConfig plugin
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> ... <properties> ... <!-- 定義autoconfig的版本，建議將此行寫在parent pom.xml中。 --> <autoconfig-plugin-version>1.2</autoconfig-plugin-version> </properties> ... <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> </project>
這樣，每次執行mvn package或者mvn install時，都會激活AutoConfig，對package目標文件進行配置。
想要避免AutoConfig，只需要一個額外的命令行參數：
第一次執行AutoConfig，無論通過何種方式（獨立命令行或maven插件），AutoConfig都會提示你修改user properties文件，以提供所需要的properties值。AutoConfig提供了一套基於文本的交互式界面來編輯這些properties。
例 13.17. 交互式編輯properties
╭───────────────────────┈┈┈┈
│
│ 您的配置文件需要被更新：
│
│ file:/.../antx.properties
│
│ 這個文件包括了您個人的特殊設置，
│ 包括服務器端口、您的郵件地址等內容。
│
└───────┈┈┈┈┈┈┈┈┈┈┈
如果不更新此文件，可能會導致配置文件的內容不完整。
您需要現在更新此文件嗎? [Yes][No] y
當你通過交互式界面填寫了所有properties的值，並通過了AutoConfig的驗證以后，AutoConfig就開始生成配置文件：
即將保存到文件"file:/.../antx.properties"中, 確定? [Yes][No] y
╭───────────────────────┈┈┈┈
│ 保存文件 file:/.../antx.properties...
│┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
│petstore.loggingLevel = warn
│petstore.loggingRoot = ${petstore.work}/logs
│petstore.upload = ${petstore.work}/upload
│petstore.work = /tmp
└───────┈┈┈┈┈┈┈┈┈┈┈
已保存至文件: file:/.../antx.properties
Loading file:/.../antx.properties
<jar:file:/.../Work/my/apps/petstore-webx3/target/petstore.war!/>
Generating WEB-INF/web.xml [UTF-8] => WEB-INF/web.xml [UTF-8]
<jar:file:/.../Work/my/apps/petstore-webx3/target/petstore.war!/>
Generating WEB-INF/common/resources.xml [UTF-8] => WEB-INF/common/resources.xml [UTF-8] <jar:file:/.../Work/my/apps/petstore-webx3/target/petstore.war!/> Generating log file: META-INF/autoconf/auto-config.xml.log Expanding: /.../Work/my/apps/petstore-webx3/target/petstore.war To: /.../Work/my/apps/petstore-webx3/target/petstore done.
假如發現模板中某個placeholder，並未在auto-config.xml中定義，就會出現以下錯誤：
ERROR - Undefined placeholders found in template: - Template: META-INF/autoconf/WEB-INF/web.xml - Descriptor: META-INF/autoconf/auto-config.xml - Base URL: file:/.../Work/my/apps/petstore-webx3/target/petstore/ --------------------------------------------------------------- -> petstore.loggingRoot ---------------------------------------------------------------
出現錯誤以后，Maven會報錯，並停止build過程。假如你不希望maven停止，可以用下面的命令來執行maven：
AutoConfig會生成一個日志文件，就在auto-config.xml所在的目錄下，名字為：auto-config.xml.log。
例 13.19. AutoConfig所生成的日志文件
Last Configured at: Fri Jun 18 13:54:22 CST 2010 Base URL: file:/.../Work/my/apps/petstore-webx3/target/petstore/ Descriptor: META-INF/autoconf/auto-config.xml Generating META-INF/autoconf/WEB-INF/web.xml [UTF-8] => WEB-INF/web.xml [UTF-8] Generating META-INF/autoconf/WEB-INF/common/resources.xml [UTF-8] => WEB-INF/common/resources.xml [UTF-8]
最后，讓我們查看一下AutoConfig所生成的文件，其中所有的placeholders應當被替換成你所提供的值了。
當需要配置的內容越來越多時，即使使用AutoConfig這樣的機制，也會變得不勝其煩。
假如你的項目包含了好幾個模塊，而你只負責其中的一個模塊。一般來說，你對其它模塊的配置是什么並不清楚，事實上你也懶得去關心。但是你為了運行這個項目，你不得不去配置這些模塊。假如模塊A就是一個你不想關心的模塊，但為了運行它，你需要告訴模塊A一些參數：數據庫連接的參數、域名、端口、文件目錄、搜索引擎……可你並不清楚這些參數應該取什么值。
好在AutoConfig提供了一個共享properties文件的方法。
你可以創建一系列文件：module-a-db.properites，module-a-searchengine.properties等等。每個文件中都包含了某個運行環境中的關於module A模塊的配置參數。
現在，你可以不關心module A了！你只要使用下面的命令：
同時，你的antx.properties也被簡化了，因為這里只會保存你定義的配置項，而不會包含共享的配置項。
假如共享的文件很多的話，AutoConfig還有一個貼心的功能，你可以把這些文件按目錄來組織：
例 13.22. 按目錄組織要被共享的properties文件
shared-properties/
├─test/ // 測試環境的共享配置
│ module-a-db.properties
│ module-a-searchengine.properties
│ module-b.properties
└─prod/ // 生產環境的共享配置 module-a-db.properties module-a-searchengine.properties module-b.properties
然后，你可以直接在AutoConfig中引用目錄：
AutoConfig就會為你裝載這個目錄下的所有共享配置文件。（注意，目錄必須以斜杠“/”結尾）
AutoConfig還支持從http、https或ssh服務器上取得共享配置文件，只需要將前面例子中的文件名改成http或ssh的URI就可以了：
例 13.24. 共享遠程服務器上的properties文件或目錄
autoconfig -s http://share.alibaba.com/shared-propertes/test/ …… autoconfig -s http://myname@share.alibaba.com/shared-propertes/test/ …… autoconfig -s https://share.alibaba.com/shared-propertes/test/ …… autoconfig -s https://myname@share.alibaba.com/shared-propertes/test/ …… autoconfig -s ssh://myname@share.alibaba.com/shared-propertes/test/ ……
|
|
共享遠程http服務器上的properties文件。 |
|
|
共享遠程http服務器上的properties文件，指定登錄用戶名。 |
|
|
共享遠程https服務器上的properties文件。 |
|
|
共享遠程https服務器上的properties文件，指定登錄用戶名。 |
|
|
共享遠程ssh服務器上的properties文件，必須指定用戶名。 |
由於Subversion、Git服務器是支持HTTP/HTTPS協議的，因此將properties文件存放在Subversion或Git服務器上，也是一個極好的辦法。由於采用了Subversion或Git，properties文件的版本管理問題也被一舉解決了。
需要注意的是，訪問http和ssh有可能需要驗證用戶和密碼。當需要驗證時，AutoConfig會提示你輸入用戶名和密碼。輸入以后，密碼將被保存在$HOME/passwd.autoconfig文件中，以后就不需要重復提問了。
當你使用前文所述的autoconfig –s命令來生成antx.properties文件時，你會發現antx.properties中增加了幾行特別的內容：
例 13.25. 包含共享文件、目錄信息的antx.properties文件
antx.properties.default = http://share.alibaba.com/shared-propertes/test/
如果你在-s參數中指定了多項共享properties文件或目錄，那么antx.properties中將會這樣：
antx.properties.default.1 = http://share.alibaba.com/shared-propertes/test/
antx.properties.default.2 = file:/shared-properties/test/my-1.properites antx.properties.default.3 = file:/shared-properties/test/my-2.properites
事實上，AutoConfig還支持多組共享配置，請試用下面的命令：
例 13.26. 使用多組共享配置
autoconfig -s http://share.alibaba.com/shared-propertes/test/ -n test ……
|
|
為當前共享配置定義一個名字，以后可以用這個名字來簡化命令。 |
這時，antx.properties就會是這個樣子：
antx.properties = test
antx.properties.test = http://share.alibaba.com/shared-propertes/test/
再執行：
autoconfig -s http://share.alibaba.com/shared-propertes/prod/ -n prod ……
antx.properties就會變成這個樣子：
antx.properties = prod
antx.properties.test = http://share.alibaba.com/shared-propertes/test/
antx.properties.prod = http://share.alibaba.com/shared-propertes/prod/
以后再執行，就不需要再指定-s參數了，只需用-n參數選擇一組共享properties文件即可。例如：
autoconfig -n prod …… // 使用prod生產環境的參數 autoconfig -n test …… // 使用test測試環境的參數 autoconfig …… // 不指定，則使用最近一次所選擇的共享文件
下面羅列了AutoConfig的常用的命令及參數：
一般不需要特別指定charset，除非AutoConfig自動識別系統編碼出錯，導致顯示亂碼。
| 運行AutoConfig獨立可執行程序 | autoconfig ... -c GBK |
| 運行AutoConfig maven插件 | mvn ... -Dautoconfig.charset=GBK |
默認情況下，交互模式為自動（auto）。僅當user properties中的值不滿足auto-config.xml中的定義時，才會交互式地引導用戶提供properties值。
但你可以強制打開交互模式：
| 運行AutoConfig獨立可執行程序 | autoconfig ... –i
autoconfig ... –i on |
| 運行AutoConfig maven插件 | mvn ... -Dautoconfig.interactive
mvn ... -Dautoconfig.interactive=true |
或強制關閉交互模式：
| 運行AutoConfig獨立可執行程序 | autoconfig ... –I
autoconfig ... –i off |
| 運行AutoConfig maven插件 | mvn ... -Dautoconfig.interactive=false |
默認情況下，AutoConfig會按下列順序查找user properties：
-
當前目錄/antx.properties -
當前用戶HOME目錄/antx.properties
但你可以指定一個自己的properties文件，用下面的命令：
| 運行AutoConfig獨立可執行程序 | autoconfig ... –u my.props |
| 運行AutoConfig maven插件 | mvn ... -Dautoconfig.userProperties=my.props |
默認情況下，AutoConfig只輸出重要的信息，但有時你想了解更多內部的情況，只需要用下面的命令：
| 運行AutoConfig獨立可執行程序 | autoconfig ... –v |
| 運行AutoConfig maven插件 | 不適用 |
默認情況下，AutoConfig所生成的配置文件以及日志信息會直接輸出到當前包文件或目錄中。例如以下命令會改變petstore.war的內容：
autoconfig petstore.war
但你可以指定另一個輸出文件或目錄，這樣，原來的文件或目錄就不會被修改：
| 運行AutoConfig獨立可執行程序 | autoconfig petstore.war –o petstore-configured.war |
| 運行AutoConfig maven插件 | 不適用 |
將AutoConfig和maven package phase綁定以后，每次build都會激活AutoConfig。假如你想跳過這一步，只需要下面的命令：
| 運行AutoConfig獨立可執行程序 | 不適用 |
| 運行AutoConfig maven插件 | mvn ... -Dautoconfig.skip |
AutoConfig是一個簡單而有用的小工具，彌補了Maven Filtering及類似機制的不足。但它還有不少改進的余地。
-
界面不夠直觀。如果能夠通過GUI或WEB界面來配置，就更好了。
-
Properties validator目前不易擴展。
-
缺少集成環境的支持。