［最佳实践］基于Struts2+Spring+iBatis的web应用最佳实践系列之一（自动配置篇）

这个系列的文章是先前在网上看到的，非常的好，曾经写了两篇文章来总结学习成果。但是，还是不爽，于是全面的转载！

-----------原文----------------------http://kevindude.javaeye.com/category/95142--------------------------------------------

 

 

由于最近有点时间，便想动手写点东西，其一算是对自己这段时间来项目经验的一个总结，其二也希望能和大家探讨下最佳实践这个主题。说来也怪，网络上关于这三个框架的介绍很多，整合的教程也很多，但绝大多数都属于入门级别，浅尝则止，对于探讨如何在实际项目中用好他们，如何发挥出整合后的巨大威力的文章却很少，甚至连javaEye都没有最佳实践这个分类。不知道是大家的忽视还是那些大牛们藏着掖着不愿拿出来与大家分享。但笔者觉得，再好的框架给你，你不能用好它也是白搭。同时笔者也觉得，真正好的东西不是闭门造车造出来的，而是在与外界交流中不断完善起来的。本着“不是原创的不发，没有新意的不发”的原则，笔者在此保证，虽然有些工具和类库等从网上搜集或改造而来，但本系列文章绝对原创，都是笔者在项目实践当中思考总结而来。并会在本系列最后放出一个demo以及所有源代码供下载。但同时在这里也指出，本系列不是入门教程，需要读者有一定的基础，如果对有些技术点不是很明白的话，请自行查阅相关资料（网上入门级别的介绍资料很多）。

 

作为本系列的开篇，主要讨论如何合理的管理配置文件，把这个主题放在第一位主要也考虑到本篇所介绍或涉及到的技巧、工具等其后的篇章会应用到。其实写好技术类文章也是挺难的，在实际工作中可能一个项目里就涉及到多个新的技术点，而这些技术点往往是作为一个互相联系的整体而存在的，要把涉及到的每个技术点清晰而又有条理的向读者介绍清楚确实是一大考验。闲话少叙，就此转入正题。如果诸位有一定的项目经历的话，一定会和形形色色的诸多配置打过交道，比如web应用当中的web.xml，struts2中的struts.xml，又比如iBatis中对数据源的配置。但不知道大家有没有发现，其中有些配置是部署特有的（deployment specific），比如iBatis中对数据源的配置；而有些是应用特有的（application specific），比如struts2中对拦截器的配置。对那些应用特有的配置，不管这个应用被部署到那里，这个配置都不会发生变化，而部署特有的配置则不一样，部署到不同的环境具体的配置则不一样。最典型的莫过于对数据源的配置，开发人员在开发的时候需要将应用程序连接到本地的数据库做开发用，当部署到生产环境时则需要切换到生产环境的数据库。如果不能将部署特有的配置与应用特有的配置相隔离，那么该应用的部署则会成为噩梦。

 

好在我们有Spring。那么，Spring将如何帮助我们把部署特有的配置同应用特有的配置隔离出来？Spring就象一个宝藏，只要细心发掘，总会有意向不到的收获。在Spring中有一个PropertyPlaceholderConfigurer类，使用这个类在解析bean配置中遇到${...}这样的占位符后可以从properties文件中将属性读取出来替换占位符。

 

Example XML context definition:

Xml代码

<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
<property name="driverClassName"><value>${driver}</value></property>
<property name="url"><value>jdbc:${dbname}</value></property>
</bean>

 

 

Example properties file:

Properties file代码
 

driver=com.mysql.jdbc.Driver
dbname=mysql:mydb

 

 

当然 PropertyPlaceholderConfigurer本身也要配置成一个bean，在这个bean中用以指定我们properties文件的位置。

 

Xml代码 

<bean id="propertyConfigurer"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="locations">
<list>
<value>classpath:com/meidusa/demo/dal/datasource.properties</value>
</list>
</property>
</bean>

 

 

这样我们通过使用PropertyPlaceholderConfigurer将部署特有的配置隔离到了一个properties文件里，有意思的是PropertyPlaceholderConfigurer还有一个孪生兄弟PropertyOverrideConfigurer，同样也是从properties文件中读取配置属性，但与PropertyPlaceholderConfigurer不同的是，使用PropertyOverrideConfigurer不需要再使用占位符，而是可以在bean定义中先指定一个默认值，而在properties文件中指定的值会override bean的默认值，形象的说就是PropertyOverrideConfigurer是将值从properties文件中push到bean定义中而PropertyPlaceholderConfigurer则是将值从properties文件中pull到bean定义中。

 

诸位看到这里或许会想，这篇文章里到目前为止介绍东西的基本上也是属于大路货性质，网上基本上都有。是的，这点我承认，不过写文章总得有个过渡是吧，一上来就把所有的货都倒出来也不见得就讨人喜欢。不过我保证，如果大家耐着性子看下去一定会有所收获的。

 

题外话点到为止，我们继续。在Spring中普遍使用的resourceLoader一般有三种，即classpath，file和url。在我们上面的那个例子中我们就使用了classpath resourceLoader。但是作为部署特有的配置不论使用这三种resourceLoader中的任何一种笔者都觉得不是很合适。显然，我们不想使用classpath resourceLoader，因为我们并不想将部署特有的配置打包到应用里，我们也不想使用file resourceLoader，因为在不同的部署环境中，properties文件的绝对路径并不一定相同，所以指定一个绝对路径并不是一个很好的做法。那使用url resourceLoader就更不靠谱了。既然这样，那我们还有没有更好的办法呢？首先，思路是这样的，一般而言，一个典型的部署过程是将开发人员在windows平台上开发好的应用打包然后部署到linux/Unix平台上（也有可能仍然是windows），但是不管是windows平台还是Linux或者Unix平台，都有user home目录。在windows平台上是C:/Documents and Settings/user目录下，Linux或者Unix则是在/home/user目录下，既然如此，那我们是否可以把properties文件放在user home目录下，把部署特有的配置从应用当中隔离出来，使得应用在部署的时候不需要做额外的配置工作。思路是这样的，那么具体如何做到呢？首先我们看一下下面这张类继承关系图，从图上我们可以看到PropertyPlaceholderConfigurer继承自顶层的PropertiesLoaderSupport

 



 

这个类里有一个setLocations方法，接受一个Resource类型的数组作为参数，对比上面PropertyPlaceholderConfigurer的bean配置我们就可以发现locations标签下值都会被解析成Resource，而这个resource本身则包含了访问这个resource的方法，在这里resource代表的则是properties文件。

Java代码 

/**
* Set locations of properties files to be loaded.
* <p>Can point to classic properties files or to XML files
* that follow JDK 1.5's properties XML format.
* <p>Note: Properties defined in later files will override
* properties defined earlier files, in case of overlapping keys.
* Hence, make sure that the most specific files are the last
* ones in the given list of locations.
*/
public void setLocations(Resource[] locations) {
this.locations = locations;
}

 

 

而这个解析过程应该是由applicationContext完成的。研究一下代码发现，所有的applicationContext都间接的继承或实现了ResourceLoader这个接口，这个接口主要有一个getResource方法，而Resource本身也是一个接口。

 

Resource Loader接口

Java代码 

public interface ResourceLoader {

Resource getResource(String location);

ClassLoader getClassLoader();
}

 

 

Resource接口

Java代码 

public interface Resource extends InputStreamSource {

boolean exists();

boolean isReadable();

boolean isOpen();

URI getURI() throws IOException;

File getFile() throws IOException;

Resource createRelative(String relativePath) throws IOException;

String getDescr*ption();
}

研究到这一步我们就受到一个启发，既然applicationContext通过解析后的Resource来访问这个properties文件的话，那我们是否可以通过写一个bean，这个bean实现Resource这个接口，并且由这个bean负责解析对这个properties文件访问呢？既然这个bean是一个Resource的话，那么它就可以被applicationContext装载。
假设我们的properties文件名是projectName.properties，并且这个bean接受一个名称是projectName的属性，那我们的PropertyPlaceholderConfigurer可以这样配置
Xml代码 property%3E%0A%09%09%09%09%3C%2Fbean%3E%0A%09%09%09%3C%2Flist%3E%0A%09%09%3C%2Fproperty%3E%0A%09%3C%2Fbean%3E%0A%3C%2Fbeans%3E">
<beans default-autowire="byName">
<bean id="propertyConfigurer"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="locations">
<list>
<bean class="com.meidusa.toolkit.common.spring.DefinedFileSystemResource">
<property name="projectName">
<value>demo</value>
</property>
</bean>
</list>
</property>
</bean>
</beans>

 

研究到这一步我们就受到一个启发，既然applicationContext通过解析后的Resource来访问这个properties文件的话，那我们是否可以通过写一个bean，这个bean实现Resource这个接口，并且由这个bean负责解析对这个properties文件访问呢？既然这个bean是一个Resource的话，那么它就可以被applicationContext装载。
 假设我们的properties文件名是projectName.properties，并且这个bean接受一个名称是projectName的属性，那我们的PropertyPlaceholderConfigurer可以这样配置
Xml代码 

<bean id="propertyConfigurer"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="locations">
<list>
<bean class="com.meidusa.toolkit.common.spring.DefinedFileSystemResource">
<property name="projectName">
<value>demo</value>
</property>
</bean>
</list>
</property>
</bean>
</beans>

  

 com.meidusa.toolkit.common.spring.DefinedFileSystemResource是这个bean的class。这个bean通过projectName的值来解析具体的properties文件的位置。

 

而projectName的值是应用特有的配置而不是部署特有的，通过由这个bean来解析具体的properties文件的位置，我们成功的实现了对部署特有的配置与应用特有的配置的分离。

 

因为这个类的定义很长，所以这里只放出部分代码，从下面的代码中可以看出，这个类继承了AbstractResource并实现了InitializingBean这个接口。AbstractResource是对Resource这个接口的默认实现，而InitializingBean则定义了这个类里最重要的一个方法，即afterPropertiesSet()，这个方法在projectName属性设置后被调用，正是由这个方法计算出对properties文件的访问路径。

 

Java代码 

public class DefinedFileSystemResource extends AbstractResource implements
InitializingBean {
private static Logger logger = Logger.getLogger(DefinedFileSystemResource.class);
private String projectName;
private File file;
private String path;

public DefinedFileSystemResource() {

}

public void afterPropertiesSet() throws Exception {
try{

this.path = System.getProperty("user.home");
this.path = StringUtils.cleanPath(path);
this.file = new File(path,projectName+".properties");
}finally{
logger.info("loading project config file from :"+file.getAbsolutePath());
}
}

}

 

按说到这里应该算是圆满了，但笔者还是不得不指出，使用这种方法还是有一个致命的不足之处，那就是对Spring的依赖。虽说Spring很好很强大，对几乎所有的主流框架都有一定的支持，但总有不支持的吧？特别是自己写的工具类库，比如在这个系列的下一篇我们会讨论到一个自己定制的Struts2的cookie拦截器，这个拦截器会用到一个自己定义的xml配置文件，这个配置文件里会放置一些部署特有的配置信息，遇到这种情况Spring就没辄了。那么，我们有没有一种更普遍适用的解决方案呢？

 

 答案是肯定的，这也涉及到我们这篇文章的主题，即自动化配置。在讨论这个新的方法之前，有必要先引入一下maven这个管理工具。如果诸位对maven不是很了解的话可以去Juven的博客浏览一番，在他的博客里有着对maven十分详尽的介绍，地址是http://juvenshun.javaeye.com/  不过maven并不是我们今天的主题，在这里我主要想介绍一个maven的插件，maven-autoconfig-plugin。

 

在命令行界面下运行maven命令可以得到如下输出

 

mvn help:describe -Dplugin=autoconfig -Ddetail

 

控制台输出代码 

Name: maven-autoconfig-plugin  

Descr*ption: (no descr*ption available)  

Group Id: com.meidusa.toolkit.plugin  

Artifact Id: maven-autoconfig-plugin  

Version: 1.0  

Goal Prefix: autoconfig  

  

This plugin has 1 goal:  

  

autoconfig:config  

  Descr*ption: (no descr*ption available)  

  Deprecated. No reason given  

  Implementation: com.meidusa.toolkit.plugin.autoconfig.AutoConfig  

  Language: java  

  

  Available parameters:  

  

    charset  

      (no descr*ption available)  

      Deprecated. No reason given  

  

    excludeDescr*ptors  

      excludeDescr*ptors  

      Deprecated. No reason given  

  

    excludePackages  

      excludePackages  

      Deprecated. No reason given  

  

    includeDescr*ptors  

      includeDescr*ptors  

      Deprecated. No reason given  

  

    includePackages  

      includePackages  

      Deprecated. No reason given  

  

    projectName  

      projectName  

      Deprecated. No reason given  

 

从上面的输出中我们可以看到这个autoconfig插件有且只有一个goal，那就是config。另外支持的参数有charset，excludeDescr*ptors，excludePackages，includeDescr*ptors，includePackages，projectName。

 

一个典型的应用是在父项目的pom中将这个插件的config goal bind到initialize这个phase中，也就是说在maven构建的初始阶段即运行autoconfig这个插件，如果是第一次运行，它会根据includeDescr*ptors参数扫描所有的自动配置符文件，通过运行一个向导配置好user home目录下的projectName.properties属性文件。若projectName.properties属性文件已经存在并已配置好的时候，这个插件会根据projectName的值自动扫描这个文件并读取里面的值，同时includeDescr*ptors参数包含的自动配置描述符文件中若有<script>项，插件会根据读取的属性渲染定义在配置描述符里的模板生成真正的配置文件，即完成了配置的自动化。在子项目中则把这个插件的config goal bind到install phase中，这样在打包的时候就可以将自动配置好的配置文件打包进war中。

 

在父项目pom.xml中的配置片段如下

 

Xml代码 

<plugin>
<groupId>com.meidusa.toolkit.plugin</groupId>
<artifactId>maven-autoconfig-plugin</artifactId>
<configuration>
<projectName>demo</projectName>
<includeDescr*ptors>deploy/**/auto-config.xml</includeDescr*ptors>
</configuration>
<executions>
<execution>
<phase>initialize</phase>
<goals>
<goal>config</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>

 

 

在子项目pom.xml中配置片段如下

 

Xml代码 

<plugin>
<groupId>com.meidusa.toolkit.plugin</groupId>
<artifactId>maven-autoconfig-plugin</artifactId>
<configuration>
<projectName>demo</projectName>
<includePackages>target/*.war</includePackages>
<includeDescriptors>src/**/auto-config.xml</includeDescriptors>
</configuration>
<executions>
<execution>
<phase>install</phase>
<goals>
<goal>config</goal>
</goals>
</execution>
</executions>
</plugin>

 

 

groupId和artifactId标识了这个插件的坐标，configuration标签则指定了运行这个插件时给的参数及其值，executions标签及其子标签则表明如何将这个插件绑定到使用maven构建的生命周期中。

对于maven的配置文件pom.xml及生命周期以及插件的goal等概念读者请自行查询相关资料，这里不再赘述。

 

 autoconfig的描述符本身也是一个xml配置文件，group定义了properties属性，script则定义了需要渲染的模板

 

Xml代码 

<?xml version="1.0" encoding="utf-8"?>
<config>
<group name="usercookie setting" description="用户cookie的配置">
<property name="cookie.encryptKey" defaultValue="ei*736TR" description="cookie加密的key,至少8位" />
<property name="cookie.loginUrl" defaultValue="http://demo.meidusa.com:8080" description="cookie失败后登录的地址" />
<property name="cookie.algorithm" defaultValue="DES" description="cookie加密的算法" />
<property name="cookie.domain" defaultValue="demo.meidusa.com" description="cookie domain" />
</group>
<mce:script type="text/javascript"><!--

<generate template="cookieMapping.xml" destfile="deploy/conf/cookieMapping.xml" charset="utf-8"/>

// --></mce:script>
</config>

 

 

 

 cookie配置文件的模板，可以看到需要被渲染替换的属性占位符。

 

Xml代码 

 

假设projectName是demo，在user home目录下demo.properties文件的内容可以是

 

Properties文件代码 

cookie.algorithm   = DES
cookie.domain      = www.meidusa.com
cookie.encryptKey  = ei*736TR
cookie.loginUrl    = http://www.meidusa.com:8080/account/signin.html

 

 最终渲染出来的配置文件是

 

Xml代码 

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE cookieMapping SYSTEM "cookieMapping.dtd">
<cookieMapping
cookieClass="com.meidusa.pirateweb.web.account.Cookie"
encryptKey="ei*736TR"
loginUrl="http://www.meidusa.com:8080/account/signin.html" algorithm="DES" maxLifeTime="1440" maxIdleTime="-1">

<cookie cookieName="meidusa_cookie2" innerCookieName="loginId">
<property name="age">1000</property>
<property name="domain">www.meidusa.com</property>
<property name="writable">true</property>
<property name="secure">true</property>
<property name="path">/</property>
</cookie>

<cookie cookieName="meidusa_mask" innerCookieName="mask">
<property name="age">1000</property>
<property name="domain">www.meidusa.com</property>
<property name="writable">true</property>
<property name="secure">true</property>
<property name="path">/</property>
</cookie>
</cookieMapping>

 

 这里我们先不管这个cookie配置文件是作什么用的（本系列下一篇会谈到），但是我们可以看到域名，登录的url等部署特有的被自动配置了。