BlogJava-lanxin1020-随笔分类-spring

Introducing to Spring Framework (转)

lanxin1020 — Tue, 07 Apr 2009 15:30:00 GMT

Introducing to Spring Framework

作者：Rod Johnson
译者：yanger，taowen
校对：taowen

关于Spring Framework，今年夏天你可能已经听见很多的议论。在本文中,我将试图解释Spring能完成什么，和我怎么会认为它能帮助你开发J2EE应用程序。

又来一个framework？

你可能正在想“不过是另外一个的framework”。当已经有许多开放源代码(和专有) J2EE framework时，为什么你还要耐下心子读这篇文章或去下载Spring Framework？

我相信Spring是独特的，有几个原因：

它关注的领域是其他许多流行的Framework未曾关注的。Spring要提供的是一种管理你的业务对象的方法。

Spring既是全面的又是模块化的。Spring有分层的体系结构，这意味着你能选择仅仅使用它任何一个独立的部分，而它的架构又是内部一致。因此你能从你的学习中，得到最大的价值。例如，你可能选择仅仅使用Spring来简单化JDBC的使用，或用来管理所有的业务对象。

它的设计从一开始就是要帮助你编写易于测试的代码。Spring是使用测试驱动开发的工程的理想框架。

Spring不会给你的工程添加对其他的框架依赖。Spring也许称得上是个一站式解决方案，提供了一个典型应用所需要的大部分基础架构。它还涉及到了其他framework没有考虑到的内容。

尽管它仅仅是一个从2003年2月才开始的开源项目，但Spring有深厚的历史根基。这个开源工程是起源自我在2002年晚些时候出版的《Expert One-on-One J2EE设计与开发》书中的基础性代码。这本书展示了Spring背后的基础性架构思想。然而，对这个基础架构的概念可以追溯到2000年的早些时候,并且反映了我为一系列商业工程开发基础结构的成功经验。

2003年1月，Spring已经落户于SourceForge上了。现在有10个开发人员，其中6个是高度投入的积极分子。

Spring架构上的好处

在我们进入细节之前，让我们来看看Spring能够给工程带来的种种好处：

Spring能有效地组织你的中间层对象，不管你是否选择使用了EJB。如果你仅仅使用了Struts或其他为J2EE的 API特制的framework，Spring致力于解决剩下的问题。

Spring能消除在许多工程中常见的对Singleton的过多使用。根据我的经验，这是一个很大的问题，它降低了系统的可测试性和面向对象的程度。

通过一种在不同应用程序和项目间一致的方法来处理配置文件，Spring能消除各种各样自定义格式的属性文件的需要。曾经对某个类要寻找的是哪个魔法般的属性项或系统属性感到不解，为此不得不去读Javadoc甚至源编码？有了Spring，你仅仅需要看看类的JavaBean属性。 Inversion of Control的使用（在下面讨论）帮助完成了这种简化。

通过把对接口编程而不是对类编程的代价几乎减少到没有，Spring能够促进养成好的编程习惯。

Spring被设计为让使用它创建的应用尽可能少的依赖于他的APIs。在Spring应用中的大多数业务对象没有依赖于Spring。

使用Spring构建的应用程序易于单元测试。

Spring能使EJB的使用成为一个实现选择,而不是应用架构的必然选择。你能选择用POJOs或local EJBs来实现业务接口，却不会影响调用代码。

Spring帮助你解决许多问题而无需使用EJB。Spring能提供一种EJB的替换物，它们适用于许多web应用。例如，Spring能使用AOP提供声明性事务管理而不通过EJB容器，如果你仅仅需要与单个数据库打交道，甚至不需要一个JTA实现。

Spring为数据存取提供了一个一致的框架,不论是使用的是JDBC还是O/R mapping产品（如Hibernate）。

Spring确实使你能通过最简单可行的解决办法来解决你的问题。而这是有有很大价值的。

Spring做了些什么？

Spring提供许多功能，在此我将依次快速地展示其各个主要方面。

任务描述

首先,让我们明确Spring范围。尽管Spring覆盖了许多方面，但我们对它应该涉什么，什么不应该涉及有清楚的认识。

Spring的主要目的是使J2EE易用和促进好编程习惯。

Spring不重新轮子。因此，你发现在Spring中没有logging，没有连接池，没有分布式事务调度。所有这些东西均有开源项目提供(例如我们用于处理所有日志输出的Commons Logging以及Commons DBCP)，或由你的应用程序服务器提供了。出于同样的的原因，我们没有提供 O/R mapping层。对于这个问题已经有了像Hibernate和JDO这样的优秀解决方案。

Spring的目标就是让已有的技术更加易用。例如，尽管我们没有底层事务协调处理，但我们提供了一个抽象层覆盖了JTA或任何其他的事务策略。

Spring没有直接和其他的开源项目竞争，除非我们感到我们能提供新的一些东西。例如，象许多开发人员一样，我们从来没有对Struts感到高兴过，并且觉得到在MVC web framework中还有改进的余地。在某些领域，例如轻量级的IoC容器和AOP框架，Spring确实有直接的竞争，但是在这些领域还没有已经较为流行的解决方案。(Spring在这些领域是开路先锋。)

Spring也得益于内在的一致性。所有的开发者都在唱同样的的赞歌，基础想法依然与Expert One-on-One J2EE设计与开发中提出的差不多。并且我们已经能够在多个领域中使用一些中心的概念，例如Inversion of Control。

Spring在应用服务器之间是可移植的。当然保证可移植性总是一种挑战，但是我们避免使用任何平台特有或非标准的东西，并且支持在WebLogic，Tomcat，Resin，JBoss，WebSphere和其他的应用服务器上的用户。

Inversion of Control 容器

Spring设计的核心是 org.springframework.beans 包, 它是为与JavaBeans一起工作而设计的。这个包一般不直接被用户使用，而是作为许多其他功能的基础。

下一个层面高一些的抽象是"Bean Factory"。一个Spring bean factory 是一个通用的Factory，它使对象能够按名称获取，并且能管理对象之间的关系。

Bean factories 支持两种模式的对象：

Singleton：在此模式中，有一个具有特定名称的共享对象实例，它在查找时被获取。这是默认的，而且是最为经常使用的。它对于无状态对象是一种理想的模式。

Prototype：在此模式中，每次获取将创建一个独立的对象。例如，这可以被用于让用户拥有他们自己的对象。

由于 org.springframwork.beans.factory.BeanFactory是一个简单的接口，它能被大量底层存储方法实现。你能够方便地实现你自己的BeanFactory，尽管很少用户需要这么做。最为常用的BeanFactory定义是：

XmlBeanFactory：可解析简单直观的定义类和命名对象属性的XML结构。我们提供了一个DTD来使编写更容易。

ListableBeanFactoryImpl：提供了解析存放在属性文件中的bean定义的能力，并且可通过编程创建BeanFactories。

每个bean定义可能是一个POJO（通过类名和JavaBean初始属性定义），或是一个FactoryBean。FactoryBean接口添加了一个间接层。通常，这用于创建使用AOP或其他方法的代理对象：例如，添加声明性事务管理的代理。（这在概念上和EJB的interception相似，但实现得更简单。）

BeanFactories能在一个层次结构中选择性地参与，继承ancestor（祖先）的定义。这使得在整个应用中公共配置的共享成为可能，虽然个别资源，如controller servlets，还拥有他们自己的独立的对象集合。

这种使用JavaBeans的动机在《Expert One-on-One J2EE Design and Development》的第四章中有描述，在TheServerSide网站上的有免费的PDF版本(http://www.theserverside.com/resources/article.jsp?l=RodJohnsonInterview)。

通过BeanFactory概念，Spring成为一个Inversion of Control的容器。(我不怎么喜欢container这个词，因为它使人联想到重量级容器，如EJB容器。Spring的BeanFactory是一个可通过一行代码创建的容器，并且不需要特殊的部署步骤。)

Inversion of Control背后的概念经常表述为Hollywood原则的：“Don’t call me， I’ll call you。” IoC将控制创建的职责搬进了框架中，并把它从应用代码脱离开来。涉及到配置的地方，意思是说在传统的容器体系结构中，如EJB，一个组件可以调用容器并问“我需要它给我做工作的对象X在哪里?”；使用IoC容器则只需指出组件需要X对象，在运行时容器会提供给它。容器是通过查看方法的参数表（例如JavaBean的属性）做到的，也可能根据配置数据如XML。

IoC有几个重要的好处，例如：

因为组件不需要在运行时间寻找合作者，所以他们可以更简单的编写和维护。在Spring版的IoC里，组件通过暴露JavaBean的setter方法表达他们依赖的其他组件。这相当于EJB通过JNDI来查找，EJB查找需要开发人员编写代码。

同样原因，应用代码更容易测试。JavaBean属性是简单的，属于Java核心的，并且是容易测试的：仅编写一个自包含的Junit测试方法用来创建对象和设置相关属性即可。

一个好的IoC实现保留了强类型。如果你需要使用一个通用的factory来寻找合作者，你必须通过类型转换将返回结果转变为想要的类型。这不是一个大不了的问题，但是不雅观。使用IoC，你在你的代码中表达了强类型依赖，框架将负责类型转换。这意味着在框架配置应用时，类型不匹配将导致错误；在你的代码中，你无需担心类型转换异常。

大部分业务对象不依赖于IoC容器的APIs。这使得很容易使用遗留下来的代码，且很容易的使用对象无论在容器内或不在容器内。例如，Spring用户经常配置Jakarta Commons DBCP数据源为一个Spring bean：不需要些任何定制代码去做这件事。我们说一个IoC容器不是侵入性的：使用它并不会使你的代码依赖于它的APIs。任何JavaBean在Spring bean factory中都能成为一个组件。

最后应该强调的是，IoC 不同于传统的容器的体系结构，如EJB，应用代码最小程度地依靠于容器。这意味着你的业务对象可以潜在的被运行在不同的IoC 框架上——或者在任何框架之外——不需要任何代码的改动。

以我和其他Spring用户的经验来说，再怎么强调IoC给应用程序代码带来的好处也不为过。

IoC不是一个新概念，但是它在J2EE团体里面刚刚到达黄金时间。有一些可供选择的IoC 容器: 例如 Apache Avalon, PicoContainer 和 HiveMind。Avalon 从没怎么流行，尽管它很强大而且有很长的历史。Avalon相当的重和复杂，并且看起来比新的IoC解决方案更具侵入性。 PicoContainer是一个轻量级而且更强调通过构造函数表达依赖性而不是JavaBean 属性。与 Spring不同，它的设计允许每个类型一个对象的定义(可能是因为它拒绝任何Java代码外的元数据导致的局限性)。在Spring， PicoContainer 和其他 IoC frameworks之间做比较，可参看文章Spring网站上的 "The Spring Framework - A Lightweight Container"位于http://www.springframework.org/docs/lightweight_container.html。这个页面里面包含了PicoContainer站点的链接。

Spring BeanFactories 是非常轻量级的。用户已经成功地将他们应用在applets和单独的Swing应用中。(它们也很好地工作在 EJB容器中。) 没有特殊的部署步骤和察觉得到的启动时间。这个能力表明一个容器在应用的任何层面几乎立即可以发挥非常大的价值。

Spring BeanFactory 概念贯穿于Spring始终，而且是Spring如此内在一致的关键原因。在IoC容器中，Spring也是唯一的，它使用IoC作为基础概念贯穿于整个功能丰富的框架。

对应用开发人员，最重要的是，一个或多个BeanFactory提供了一个定义明确的业务对象层。这类似于local session bean层，但比它更简单。与EJBs不同，在这个层中的对象可能是相关的，并且他们的关系被拥有它们的factory管理。有一个定义明确的业务对象层对于成功的体系结构是非常重要的。

Spring ApplicationContext 是BeanFactory的子接口，为下列东西提供支持：

信息查找，支持着国际化

事件机制，允许发布应用对象以及可选的注册以接收到事件

可移植的文件和资源访问

XmlBeanFactory 例子

Spring用户通常在XML的“bean定义”文件中配置他们的应用。Spring的XML bean定义文档的根是<beans> 元素。该元素包含一个或多个 <bean>定义。我们一般给每个bean定义的指定类和属性。我们还必须指定ID作为标识，这将成为在代码中使用该bean的名字。

让我们来看一个简单的例子，它配置了三个应用程序对象，之间的关系在J2EE应用中常常能够看到：

J2EE DataSource

使用DataSource的DAO

在处理过程中使用DAO的业务对象

在下面的例子中，我们使用一个来自Jakarta Commons DBCP项目的BasicDataSource。这个class（和其他许多已有的 class一样）可以简单地被应用在Spring bean factory中，只要它提供了JavaBean格式的配置。需要在shutdown时被调用的Close方法可通过Spring的"destroy-method"属性被注册，以避免BasicDataSource需要实现任何Spring 的接口。

代码:
<beans>

<bean id="myDataSource"
class="org.apache.commons.dbcp.BasicDataSource"
destroy-method="close">
    <property name="driverClassName"><value>com.mysql.jdbc.Driver</value></property>
    <property name="url"><value>jdbc:mysql://localhost:3306/mydb</value></property>
    <property name="username"><value>root</value></property>
</bean>

BasicDataSource中我们感兴趣的所有属性都是String类型的，因此我们用<value>元素来指定他们的值。如果必要的话，Spring使用标准的 JavaBean属性编辑器机制来把String转换为其他的类型。

现在，我们定义DAO，它有一个对DataSource的bean引用。Bean间关系通过<ref>元素来指定：

代码:
<bean id="exampleDataAccessObject"
      class="example.ExampleDataAccessObject">
    <property name="dataSource"><ref bean="myDataSource"/></property>
</bean>

The business object has a reference to the DAO, and an int property (exampleParam):
<bean id="exampleBusinessObject"
      class="example.ExampleBusinessObject">
    <property name="dataAccessObject"><ref bean="exampleDataAccessObject"/></property>
    <property name="exampleParam"><value>10</value></property>
</bean>

</beans>

对象间的关系一般在配置中明确地设置，象这个例子一样。我们认为这样做是件好事情。然而Spring还提供了我们称做"autowire"的支持，一个 la PicoContainer，其中它指出了bean间的依赖关系。这样做的局限性——PicoContainer也是如此——是如果有一个特殊类型的多个Bean，要确定那个类型所依赖的是哪个实例是不可能。好的方面是，不满足的依赖可以在factory初始化后被捕获到。（Spring 也为显式的配置提供了一种可选的依赖检查，它可以完成这个目的）

在上面的例子中，如果我们不想显式的编写他们的关系，可使用如下的autowire特性：

代码:
<bean id="exampleBusinessObject"
   class="example.ExampleBusinessObject"
   autowire="byType">

    <property name="exampleParam"><value>10</value></property>
</bean>

使用这个特性，Spring会找出exampleBusinessObject的dataSource属性应该被设置为在当前BeanFactory中找到的DataSource实现。在当前的BeanFactory中，如果所需要类型的bean不存在或多于一个，将产生一个错误。我们依然要设置 exampleParam属性，因为它不是一个引用。

Autowire支持和依赖检查刚刚加入CVS并将在Spring 1.0 M2(到10/20,2003)中提供。本文中所讨论的所有其他特性都包含在当前1.0 M1版本中。

把管理从Java代码中移出来比硬编码有很大的好处，因为这样可以只改变XML文件而无需改变一行Java代码。例如，我们可以简单地改变 myDataSource的bean定义引用不同的bean class以使用别的连接池，或者一个用于测试的数据源。 XML节变成另一种，我们可以用 Spring的JNDI location FactoryBean从应用服务器获取一个数据源。

现在让我们来看看例子中业务对象的java 代码。注意下面列出的代码中没有对Spring的依赖。不像EJB容器，Spring BeanFactory不具有侵入性：在应用对象里面你通常不需要对Spring的存在硬编码。

代码:
public class ExampleBusinessObject implements MyBusinessObject {

   private ExampleDataAccessObject dao;
   private int exampleParam;

   public void setDataAccessObject(ExampleDataAccessObject dao) {
      this.dao = dao;
   }

   public void setExampleParam(int exampleParam) {
      this.exampleParam = exampleParam;
   }

   public void myBusinessMethod() {
      // do stuff using dao
   }
}

注意那些property setter，它们对应于bean定义文档中的XML引用。这些将在对象被使用之前由Spring调用。

这些应用程序的bean不需要依赖于Spring：他们不需要实现任何Spring的接口或者继承Spring的类。他们只需要遵守JavaBeans的命名习惯。在Spring 应用环境之外重用它们是非常简单的，例如，在一个测试环境中。只需要用它们的缺省构造函数实例化它们，并且通过调用 setDataSource()和setExampleParam()手工设置它的属性。如果你想以一行代码支持程序化的创建，只要你有一个无参数的构造器，你就可以自由定义其他需要多个属性的构造函数。

注意在业务接口中没有声明将会一起使用的JavaBean属性。他们是一个实现细节。我们可以“插入”带有不同bean属性的不同的实现类而不影响连接着的对象或者调用的代码。

当然，Spring XML bean factories 有更多的功能没有在这里描述，但是，应当让你对基本使用有了一些感觉。以及，简单的属性，有 JavaBean属性编辑器的属性，Spring可以自动处理lists，maps和java.util.Properties。

Bean factories 和application contexts 通常和J2EE server定义的一个范围相关联，例如：

Servlet context.：在spring 的MVC 框架里, 每一个包含common objects的web 应用都定义有一个应用程序的 context。Spring提供了通过listener或者servlet实例化这样的context的能力而不需要依赖于Spring 的MVC 框架，因而它也可以用于Struts，WebWork 或者其他的web框架之中。

A Servlet：在Spring MVC 框架里每一个servlet控制器都有它自己的应用程序context，派生于根（全应用程序范围的）应用程序context。在Struts或者其他MVC框架中实现这些也很容意。

EJB：Spring 为EJB提供方便的超类，它们简化了EJB的创建并且提供了一个从EJB Jar 文件中的XML文档载入的BeanFactory。

这些J2EE规范提供的hook通常避免了使用Singleton来创造一个bean factory。

然而，如果我们愿意的话可以用代码创建一个BeanFactory，虽然是没有什么意义的。例如，我们在以下三行代码中可以创建bean factory并且得到一个业务对象的引用：

代码:
InputStream is = getClass().getResourceAsStream("myFile.xml");
XmlBeanFactory bf = new XmlBeanFactory(is);
MyBusinessObject mbo = (MyBusinessObject) bf.getBean("exampleBusinessObject");

这段代码将能工作在一个应用服务器之外：甚至不依赖J2EE，因为Spring 的IoC容器是纯java的。

JDBC 抽象和数据存储异常层次

数据访问是Spring 的另一个闪光点。

JDBC 提供了还算不错的数据库抽象，但是需要用痛苦的API。这些问题包括：

需要冗长的错误处理代码来确保ResultSets，Statements以及（最重要的）Connections在使用后关闭。这意味着对JDBC的正确使用可以快速地导致大量的代码量。它还是一个常见的错误来源。Connection leak可以在有负载的情况下快速宕掉应用程序。

SQLException相对来说不能说明任何问题。JDBC不提供异常的层次，而是用抛出SQLException来响应所有的错误。找出到底哪里出错了——例如，问题是死锁还是无效的SQL？——要去检查SQLState或错误代码。这意味着这些值在数据库之间是变化的。

Spring用两种方法解决这些问题：

提供API，把冗长乏味和容易出错的异常处理从程序代码移到框架之中。框架处理所有的异常处理；程序代码能够集中精力于编写恰当的SQL和提取结果上。

为你本要处理SQLException程序代码提供有意义的异常层次。当Spring第一次从数据源取得一个连接时，它检查元数据以确定数据库。它使用这些信息把SQLException映射为自己从org.springframework.dao.DataAccessException派生下来的类层次中正确的异常。因而你的代码可以与有意义的异常打交道，并且不需要为私有的SQLState或者错误码担心。Spring的数据访问异常不是JDBC特有的，因而你的DAO并不一定会因为它们可能抛出的异常而绑死在JDBC上。

Spring提供两层JDBC API。第一个时，在org.springframework.jdbc.core包中，使用回调机制移动控制权——并且因而把错误处理和连接获取和释放——从程序的代码移到了框架之中。这是一种不同的Inversion of Control，但是和用于配置管理的几乎有同等重要的意义。

Spring使用类似的回调机制关注其他包含特殊获取和清理资源步骤的API，例如JDO（获取和释放是由PersistenceManager完成的），事务管理（使用JTA）和JNDI。Spring中完成这些回调的类被称作template。

例如，Spring的JdbcTemplate对象能够用于执行SQL查询并且在如下的列表中保存结果：

代码:
JdbcTemplate template = new JdbcTemplate(dataSource);
final List names = new LinkedList();
template.query("SELECT USER.NAME FROM USER",
   new RowCallbackHandler() {
      public void processRow(ResultSet rs) throws SQLException {
         names.add(rs.getString(1));
      }
   });

注意回调中的程序代码是能够自由抛出SQLException的：Spring将会捕捉到这些异常并且用自己的类层次重新抛出。程序的开发者可以选择哪个异常，如果有的话，被捕捉然后处理。

JdbcTemplate提供许多支持不同情景包括prepared statements和批量更新的方法。Spring的JDBC抽象有比起标准JDBC来说性能损失非常小，甚至在当应用中需要的结果集数量很大的时候。

在org.springframework.jdbc.object包中是对JDBC的更高层次的抽象。这是建立在核心的JDBC回调功能基础纸上的，但是提供了一个能够对RDBMS操作——无论是查询，更新或者是存储过程——使用Java对象来建模的API。这个API部分是受到JDO查询API的影响，我发现它直观而且非常有用。

一个用于返回User对象的查询对象可能是这样的：

代码:

class UserQuery extends MappingSqlQuery {

   public UserQuery(DataSource datasource) {
      super(datasource, "SELECT * FROM PUB_USER_ADDRESS WHERE USER_ID = ?");
      declareParameter(new SqlParameter(Types.NUMERIC));
      compile();
   }

   // Map a result set row to a Java object
   protected Object mapRow(ResultSet rs, int rownum) throws SQLException {
      User user = new User();
      user.setId(rs.getLong("USER_ID"));
      user.setForename(rs.getString("FORENAME"));
      return user;
   }

   public User findUser(long id) {
      // Use superclass convenience method to provide strong typing
      return (User) findObject(id);
   }
}

这个类可以在下面用上：
代码:

User user = userQuery.findUser(25);

这样的对象经常可以用作DAO的inner class。它们是线程安全的，除非子类作了一些超出常规的事情。

在org.springframework.jdbc.object包中另一个重要的类是StoredProcedure类。Spring让存储过程通过带有一个业务方法的Java类进行代理。如果你喜欢的话，你可以定义一个存储过程实现的接口，意味着你能够把你的程序代码从对存储过程的依赖中完全解脱出来。

Spring数据访问异常层次是基于unchecked（运行时）exception的。在几个工程中使用了Spring之后，我越来越确信这个决定是正确的。

数据访问异常一般是不可恢复的。例如，如果我们不能链接到数据库，某个业务对象很有可能就不能完成要解决的问题了。一个可能的异常是 optimistic locking violation，但是不是所有的程序使用optimistic locking。强制编写捕捉其无法有效处理的致命的异常通常是不好的。让它们传播到上层的handler，比如servlet或者EJB 容器通常更加合适。所有的Spring对象访问异常都是 DataAccessException的子类，因而如果我们确实选择了捕捉所有的Spring数据访问异常，我们可以很容易做到这点。

注意如果我们确实需要从unchecked数据访问异常中恢复，我们仍然可以这么做。我们可以编写代码仅仅处理可恢复的情况。例如，如果我们认为只有optimistic locking violation是可恢复的，我们可以在Spring的DAO中如下这么写：

代码:

try {
   // do work
}
catch (OptimisticLockingFailureException ex) {
   // I'm interested in this
}

如果Spring的数据访问异常是checked的，我们需要编写如下的代码。注意我们还是可以选择这么写：
代码:

try {
   // do work
}
catch (OptimisticLockingFailureException ex) {
   // I'm interested in this
}
catch (DataAccessException ex) {
   // Fatal; just rethrow it
}

第一个例子的潜在缺陷是——编译器不能强制处理可能的可恢复的异常——这对于第二个也是如此。因为我们被强制捕捉base exception （DataAccessException），编译器不会强制对子类（OptimisticLockingFailureException）的检查。因而编译器可能强制我们编写处理不可恢复问题的代码，但是对于强制我们处理可恢复的问题并未有任何帮助。

Spring对于数据访问异常的unchecked使用和许多——可能是大多数——成功的持久化框架是一致的。（确实，它部分是受到JDO的影响。） JDBC是少数几个使用checked exception的数据访问API之一。例如TopLink和JDO大量使用 unchecked exception。Gavin King现在相信Hibernate也应该选择使用unchecked exception。

Spring的JDBC能够用以下办法帮助你：

你决不需要在使用JDBC时再编写finally block。

总的来说你需要编写的代码更少了

你再也不需要挖掘你的RDBMS的文档以找出它为错误的列名称返回的某个罕见的错误代码。你的程序不再依赖于RDBMS特有的错误处理代码。

无论使用的是什么持久化技术，你都会发现容易实现DAO模式，让业务代码无需依赖于任何特定的数据访问API。

在实践中，我们发现所有这些都确实有助于生产力的提高和更少的bug。我过去常常厌恶编写JDBC代码；现在我发现我能够集中精力于我要执行的SQL，而不是烦杂的JDBC资源管理。

如果需要的话Spring的JDBC抽象可以独立使用——不强迫你把它们用作Spring的一部分。
O/R mapping 集成

当然你经常需要使用O/R mapping，而不是使用关系数据访问。你总体的应用程序框架也必须支持它。因而提供了对Hibernate 2.x和 JDO的集成支持。它的数据访问架构使得它能和任何底层的数据访问技术集成。Spring和Hibernate集成得尤其好。

为什么你要使用Hibernate加Spring，而不是直接使用Hibernate？

Session 管理 Spring提供有效率的，简单的以并且是安全的处理Hibernate Session。使用Hibernate的相关代码为了效率和恰当的事务处理一般需要使用相同的Hibernate “Session”对象。Spring让它容易透明地创建和绑定Session到当前的线程，要么使用声明式，AOP的method interceptor方法，要么在Java代码层面使用显式的，“template”包装类。因而 Spring解决了在Hibernate论坛上经常出现的用法问题。

资源管理 Spring的应用程序context能够处理Hiberante SessionFactories的位置和配置，JDBC数据源和其他相关资源。这使得这些值易于管理和改变。

集成的事务管理 Spring让你能够把你的Hibernate代码包装起来，要么使用声明式，AOP风格的method interceptor，要么在Java代码层面显式使用“template”包装类。在两种做法中，事务语义都为你处理了，并且在异常时也做好了恰当的事务处理（回滚，等）。如下面讨论的，你还获得了能够使用和替换不同transaction manager，而不会让你相关Hibernate代码受到影响的能力。额外的，JDBC 相关的代码能够完全事务性的和Hibernate代码集成。这对于处理没有在Hibernate实现的功能很有用。

如上描述的异常包装 Spring能够包装Hibernate异常，把它们从私有的，checked异常转换为一套抽象的运行时异常。这使得你能够仅仅在恰当的层面处理大部分不可恢复的持久化异常，而不影响样板catch/throw，和异常声明。你仍然能够在任何你需要的地方捕捉和处理异常。记住 JDBC异常（包括DB特有的方言）也被转换到相同的层次中，意味着你能在一致的编程模型中对JDBC执行相同的操作。

为了避免和厂商绑定 Hibernate是强大的，灵活的，开放源代码并且免费，但是它仍然使用私有的API。给出了一些选择，使用标准或者抽象API实现主要的程序功能通常是你想要的，当你需要因为功能，性能，或者其他考虑要转换到使用其他实现时。

让测试变简单 Spring的Inversion of Control方法使得改变Hibernate的session factories，数据源， transaction manager的实现和位置很容易，如果需要的话还能改变mapper object的实现。这使得更加容易分离和测试持久化相关的代码。
事务管理
抽象出一个数据访问的API是不够的；我们还需要考虑事务管理。JTA是显而易见的选择，但是它是一个直接用起来很笨重的API，因而许多J2EE开发者感到EJB CMT是对于事务管理唯一合理的选择。

Spring提供了它自己对事务管理的抽象。Spring提供了这些：

通过类似于JdbcTemplate的回调模板编程管理事务，比起直接使用JTA要容易多了

类似于EJB CMT的声明式事务管理，但是不需要EJB容器

Spring的事务抽象式唯一的，它不绑定到JTA或者任何其他事务管理技术。Spring使用事务策略的概念把程序代码和底层的事务架构（例如JDBC）解藕。

为什么你要关心这些？JTA不是所有事务管理的最好答案吗？如果你正在编写仅仅使用一个数据库的程序，你不需要JTA的复杂度。你不关心XA事务或者两阶段提交。你甚至不需要提供这些东西的高端应用服务器。但是另一方面，你不会希望在需要和多个数据源打交道的时候重写你的代码。

假定你决定通过直接使用JDBC或者Hibernate的事务以避免JTA带来的额外负担。一旦你需要处理多个数据源，你必须剥开所有的事务管理代码并且使用JTA事务来替代。这不是非常有吸引力的并且导致大部分J2EE程序员，包括我自己，推荐只使用全局JTA事务。然而使用Spring事务抽象，你只需要重新配置Spring让它使用JTA，而不是JDBC或者Hibernate的事务策略，就一切OK了。这是一个配置上的改变，而不是代码的改动。因而，Spring使得你能够自由缩放应用。
AOP

最近在应用AOP来解决企业关注点方面大家有了很大的兴趣，例如事务管理，这些都是EJB所要解决的。

Spring的AOP支持的首要目标是要给POJOs提供J2EE服务。这类似于JBoss 4的目标，Spring AOP由它能够在应用服务器之间移植的优势，因而没有绑死在厂商身上的风险。它既可以在web或者EJB容器中使用，也能够在WebLogic，Tomcat，JBoss，Resin， Jetty，Orion和许多其他应用服务器和web容器上使用。

Spring AOP支持method interception。所支持关键的AOP概念包括：

Interception：自定义行为能够在对接口和类的调用之前和之后插入。这类似于AspectJ术语中类似的“around advice”。

Introduction：指定advice会导致对象实现额外的接口。这混乱了继承。

静态和动态的pointcuts：在interception发生的程序执行处指定points。静态pointcuts concern函数签名；动态 pointcuts也可以在point被求值的地方考虑函数的参数。Pointcuts独立interceptors单独定义，使得标准 interceptor可以应用于不同应用程序和代码上下文。

Spring既支持有状态（一个advised对象一个实例）也支持无状态的interceptors（所有advice使用一个实例）。

Spring不支持field interception。这是一个经过深思熟虑的设计决定。我总是感觉field interception违反了封装。我比较倾向于把AOP作为补全物，而不是与OOP冲突的东西。如果在5年或者10年后，我们在AOP学习曲线上走得更远了并且觉得应该在程序设计的桌面上给AOP一个位置，我不会惊讶的。（然而在那个时候基于语言的解决方案例如AspectJ可能比它们今天看来更加具有吸引力。）

Spring使用动态代理实现AOP（其中存在一个接口）或者在运行时使用CGLIB生成字节码（这使得能够代理类）。两种方法都能够在任何应用服务器中使用。

Spring是第一个实现AOP Alliance interfaces的AOP 框架（www.sourceforge.net/projects/aopalliance）。这些是定义在不同AOP框架中能够互操作interceptors的尝试。

在TheServerSide和其他地方有一个正在进行但是不是那么引人注目的争论，就是这种interception是不是“true AOP”。我倒不怎么在意它叫什么；仅仅需要知道它是否在实践中有用就好了。我也乐于称它为“declarative middleware”（声明式中间件）。把 Spring AOP认做简单，轻量级的无状态beans的替代物，这样就不需要monolithic EJB容器了，而这些仅仅是让你能够构建有你需要的服务的容器。我不推荐advising任何一个POJO，对local SLSBs的类比有助于你理解推荐的粒度。（然而，与EJB不同的是，在恰当但是少见的情况下，你可以自由地把Spring的AOP应用到粒度更好的对象上。）

因为Spring在实例上advises 对象，而不是在class loader层面上，使用有不同advice的同一个类的多个实例是可能的，或者与advised实例一道使用unadvised 实例。

可能Spring AOP最常见的应用是声明式事务管理。这是基于前面描述的TansactionTemplate抽象上的，并且可以给任何POJO提供声明式事务管理。取决于事务策略，底层的机制可以是JTA，JDBC，Hibernate或者任何其他提供事务管理的API。

Spring的声明式事务管理类似于EJB CMT，在以下方面有些不同：

事务管理能够应用于任何POJO。我们推荐业务对象实现接口，但是这只是一个好的编程习惯的问题，而不是由框架强制的。

通过使用Spring的事务API能够在事务性POJO中实现编程回调。我们为此提供静态的方法，使用ThreadLoacal变量，因而你不需要传播诸如EJBContext这样的context对象来确保回滚。

你可以声明式地定义“回滚规则”。EJB不会在未捕捉程序异常的时候自动回滚（仅仅在unchecked exceptions和其他 Throwables的时候），应用程序开发者经常需要在任何异常发生时回滚。Spring事务管理让你能够声明式地指定什么异常什么子类能够导致自动回滚。缺省的行为和EJB是一致的，但是你能够在checked和unchecked异常时自动回滚。这个在最少化自编程回调代码方面有很大好处，而回调依赖于Spring的事务API（因为EJB的编程回调时在EJBContext中完成的）。

事务管理不绑定于JTA。如前面解释过的，Spring的事务管理能够在不同事务策略中使用。

当然还可以使用Spring AOP实现程序特有的aspects。取决于你对AOP概念的接受程度，决定你是否选择这么做，而不是Spring的能力，但是它确实非常有用。我们所见过的成功例子包括：

自定义的security interception，当安全检查的复杂度超出了J2EE安全架构的能力的时候

在开发中使用的调试和profiling aspects

发送email通知管理员用户不寻常的举动的Interceptors

程序自定的aspects能够成为消除需要许多函数的样板代码的有利武器。

Spring AOP透明地与Spring BeanFactory概念集成。包含一个来自Spring BeanFactory对象地代码不需要知道它是还是不是advised。和任何对象一样，契约实在接口和对象实现中定义的。

下面的XML片断展示了如何定义一个AOP代理：
代码:

<bean id="myTest"
   class="org.springframework.aop.framework.ProxyFactoryBean">
   <property name="proxyInterfaces">
      <value>org.springframework.beans.ITestBean</value>
   </property>
   <property name="interceptorNames">
      <list>
         <value>txInterceptor</value>
         <value>target</value>
      </list>
   </property>
</bean>

注意bean类的定义总是AOP框架的ProxyFactoryBean，虽然bean的类型在引用中使用或者由BeanFactory的getBean ()方法返回时依赖的是代理接口。（多个代理方法是被支持的。）ProxyFactoryBean的“interceptorNames”属性需要一个字符串列表。（因为如果代理是一个“prototype”而不是singleton，有状态interceptors可能需要创建新的实例，所以必须使用 Bean的名字而不是bean的引用。）列表中的名字可以是interceptor或者pointcuts（interceptors和有关它们合适被使用的信息）。列表中的“target”值自动创建一个“invoker interceptor”封装target对象。实现代理接口的是在 factory中的bean的名字。这个例子中的myTest可以和其他bean factory中的bean一样使用。例如，其他对象可以使用< ref>元素引用它而且这些引用是由Spring IoC设置的。

还可以不用BeanFactory，编程构建AOP代理，虽然这个很少用得上：

代码:

TestBean target = new TestBean();
DebugInterceptor di = new DebugInterceptor();
MyInterceptor mi = new MyInterceptor();
ProxyFactory factory = new ProxyFactory(target);
factory.addInterceptor(0, di);
factory.addInterceptor(1, mi);
// An "invoker interceptor" is automatically added to wrap the target
ITestBean tb = (ITestBean) factory.getProxy();

我们相信最好把程序装配从Java代码中移出来，而AOP也不例外。

Spring在它的AOP能力方面的直接竞争者是Jon Tirsen的Nanning Aspects（http://nanning.codehaus.org）。

我觉得AOP作为EJB的替代无提供企业服务这个用法方面的进步是重要的。随着时间，这将成为Spring很重要的关注点。
MVC web 框架

Spring包括一个强大而且高度可配置的MVC web 框架。

Spring的MVC model类似于Struts。在多线程服务对象这点上，Spring的Controller类似于Struts Action，只有一个实例处理所有客户的请求。然而，我们相信Spring的MVC比起Struts有很多优点，例如：

Spring在controllers，JavaBean，models和views提供了一个非常清晰的划分。

Spring的MVC是非常灵活的。不像Struts，它强制你的Action和Form对象进入固化的层次之中（因而你迫使你使用Java的实体继承），Spring MVC完全是基于接口的。而且，通过插入你自己的接口几乎Spring MVC 框架的所有部分都是可配置的。当然我们也提供了方便的类作为实现选择。

Spring MVC是真正的view无关的。你不会被强制使用JSP，如果你不想那么做的话。你可以使用Velocity，XSLT或其他view技术。如果你想要使用自定义的view机制——例如，你自己的模板语言——你可以简单实现Spring的View接口并且把它集成进来。

和其他对象一样，Spring的Controllers是通过IoC配置的。着使得它们易于测试，并且完美地和其他由Spring管理的对象集成。

Web层变成了业务对象层之上的薄薄一层。这鼓励了好的习惯。Struts和其他专门的web框架让你去实现你自己的业务对象；Spring提供了你应用程序所有层的集成。

如在Struts 1.1中所见的，你可以有和你在Spring MVC 应用程序中所需要的一样多的dispatcher servlets。

下面的例子展示了一个简单的Spring Controller如何能够访问定义在应用程序context中的业务对象。这个controller在它的handleRequest()方法中执行了Google搜索：

代码:

public class GoogleSearchController
      implements Controller {

   private IGoogleSearchPort google;

   private String googleKey;

   public void setGoogle(IGoogleSearchPort google) {
      this.google = google;
   }

   public void setGoogleKey(String googleKey) {
      this.googleKey = googleKey;
   }

   public ModelAndView handleRequest(
            HttpServletRequest request, HttpServletResponse response)
      throws ServletException, IOException {
      String query = request.getParameter("query");
      GoogleSearchResult result =
         // Google property definitions omitted...

         // Use google business object
         google.doGoogleSearch(this.googleKey, query,
            start, maxResults, filter, restrict,
            safeSearch, lr, ie, oe);

      return new ModelAndView("googleResults", "result", result);
   }
}

这段代码使用的prototype中，IGoogleSearchPort是一个GLUE web services代理，由 Spring FActoryBean返回。然而，Spring把controller从底层web service库中分离出来。接口可以使用普通的 Java对象，test stub，mock对象或者如下面要讨论的EJB代理实现。这个contorller不包括资源查找；除了支持它的web交互的必要代码之外没有别的什么了。

Spring还提供了数据绑定，forms，wizards和更复杂的工作流的支持。

对Spring MVC 框架的优秀简介是Thomas Risberg的Spring MVC 教程（http://www.springframework.org/docs/MVC-step-by-step/Spring-MVC-step-by-step.html）。还可以参见“Web MVC with the Spring Framework”（http://www.springframework.org/docs/web_mvc.html）。

如果你乐于使用你钟情的MVC框架，Spring的分层架构使得你能够使用Spring的其他部分而不用MVC层。我们有使用Spring做中间层管理和数据访问，但是在web层使用Struts，WebWork或者Tapestry的用户。
实现EJB

如果你选择使用EJB，Spring能在EJB实现和客户端访问EJB两方面都提供很大的好处。

对业务逻辑进行重构，把它从EJB facades中取出到POJO已经得到了广泛的认同。（不讲别的，这使得业务逻辑更容易单元测试，因为EJB严重依赖于容器而难于分离测试。）Spring为session bean和message driver bean提供了方便的超类，使得通过自动载入基于包含在EJB Jar文件中的XML文档BeanFactory让这变得很容易。

这意味着stateless session EJB可以这么获得和使用所需对象：

代码:

import org.springframework.ejb.support.AbstractStatelessSessionBean;

public class MyEJB extends AbstractStatelessSessionBean
         implements MyBusinessInterface {
   private MyPOJO myPOJO;

   protected void onEjbCreate() {
      this.myPOJO = getBeanFactory().getBean("myPOJO");
   }

   public void myBusinessMethod() {
      this.myPOJO.invokeMethod();
   }
}

假定MyPOJO是一个接口，它的实现类——以及任何它需要的配置，注入基本的属性和更多的合作者——在XML bean factory 定义中隐藏。

我们通过在ejb-jar.xmldeployment descriptor中名为ejb/BeanFactoryPath的环境变量定义告诉Spring去哪儿装载XML文档。如下：

代码:

<session>
   <ejb-name>myComponent</ejb-name>
   <local-home>com.test.ejb.myEjbBeanLocalHome</local-home>
   <local>com.mycom.MyComponentLocal</local>
   <ejb-class>com.mycom.MyComponentEJB</ejb-class>
   <session-type>Stateless</session-type>
   <transaction-type>Container</transaction-type>

   <env-entry>
      <env-entry-name>ejb/BeanFactoryPath</env-entry-name>
      <env-entry-type>java.lang.String</env-entry-type>
      <env-entry-value>/myComponent-ejb-beans.xml</env-entry-value></env-entry>
   </env-entry>
</session>

myComponent-ejb-beans.xml 文件将会从classpath装载：在本例中，是EJB Jar文件的根目录。每个EJB都能指定自己的XML文档，因而这个机制能在每个EJB Jar文件中使用多次。

Spring 的超类实现了EJB中诸如setSessionContext()和ejbCreate()的生命周期管理的方法，让应用程序开发者只需选择是否实现Spring的onEjbCreate()方法。
使用EJB

Spring还让实现EJB变得更加容易。许多EJB程序使用Service Locator和Business Delegate模式。这些比在客户代码中遍布JNDI查找强多了，但是它们常见的实现方式有显著的缺点，例如：

使用EJB的典型代码依赖Service Locator或者Business Delegate singletons，使得测试难于进行。

在Service Locator模式没有使用Business Delegate的情况下，程序代码还要在EJB home中调用create()方法，并且处理可能导致的异常。因而仍然绑定在EJB API身上，忍受着EJB 编程模型的复杂度。

实现Business Delegate模式通常导致显著的代码重复，其中我们必须编写大量仅仅是调用EJB同等方法的方法。

基于这些和其他原因，传统的EJB访问，如在Sun Adventure Builder和OTN J2EE Virtual Shopping Mall中展示的那样，会降低生产率并且带来显著的复杂度。

Spring通过引入codeless business delegate前进了一步。有了Spring，你不再需要再编写另一个 Service Locator，另一个JNDI查找，或者在硬编码的Business Delegate中重复代码，除非你肯定这增加了价值。

例如，假定我们有使用local EJB的web controller。我们将遵循最佳实践，使用 EJB Business Methods Interface模式，EJB的local interface extend非EJB专有的业务方法接口。（这么做的主要的一个原因是确保在本地接口和bean实现类中方法签名的自动同步。）让我们调用这个业务方法接口MyComponent。当然我们还需要实现local home接口并且提供实现SessionBean和MyComponent业务方法的bean的实现类。

用了Spring EJB 访问，我们把我们的web层controller和EJB实现挂接上所需要进行的Java编码仅仅是在我们的controller中暴露一个类型MyComponent的setter方法。这将如下保存作为实例变量的引用：

代码:

private MyComponent myComponent;

public void setMyComponent(MyComponent myComponent) {
   this.myComponent = myComponent;
}

我们随后在任何业务方法中使用这个实例变量。

Spring自动完称剩下的工作，通过像这样的XML bean定义。LocalStatelessSessionProxyFactoryBean是一个可以用于任何EJB的通用factory bean。它创建的对象能够自动被Spring转型为MyComponent类型。

代码:

<bean id="myComponent"
class="org.springframework.ejb.access.LocalStatelessSessionProxyFactoryBean">

   <property name="jndiName"><value>myComponent</value></property>
   <property name="businessInterface"><value>com.mycom.MyComponent</value></property>
</bean>

<bean id="myController"
   class = "com.mycom.myController"
>
   <property name="myComponent"><ref bean="myComponent"/></property>
</bean>

在幕后有许多魔法般的事情发生，Spring AOP framework的殷勤，虽然不强迫你使用AOP的概念享受这些结果。 “myComponent”bean定义为EJB创建一个代理，它实现了业务方法的接口。EJB local home在启动的时候被缓存，因而只需要一次JNDI查找。每次EJB被调用的时候，代理调用local EJB中的create()方法并且调用EJB中对应的业务方法。

myController bean定义为这个代理设置controller类的myController属性。

这个EJB访问机制极大简化了应用程序的代码：

Web层的代码不依赖于EJB的使用。如果你想要使用POJO，mock object或者其他test stub替代EJB引用，我们可以简单地改动一下myComponent bean定义而不影响一行Java代码

我们还不需要写一行JNDI查找或者其他EJB plumbing code。

在实际程序中的性能测试和经验标明这种方法（包括对目标EJB的反射调用）的性能影响是很小的，在典型的应用中检测不出。记住无论如何我们都不希望使用fine-grained的EJB调用，因为会有有关应用服务器上的EJB的底层架构方面的代价。

我们可以把相同方法应用于远程EJB，通过类似 org.springframework.ejb.access.SimpleRemoteStatelessSessionProxyFactoryBean factory bean 的方法。然而我们无法隐藏远程EJB的业务方法接口中的RemoteException。
测试

如你可能已经注意到的，我和其他Spring开发这是全面单元测试重要性的坚定支持者。我们相信框架被彻底单元测试过的是非常重要的，而且我们框架设计的主要目标是让建立在框架之上的程序易于单元测试。

Spring自身有一个极好的单元测试包。我们的1.0 M1的单元测试覆盖率是75%，而且我们希望在1.0 RC1的时候能够达到80%的单元测试覆盖率。我们发现在这个项目中测试优先的开发带来的好处是实实在在的。例如，它使得作为国际化分布式开发团队的工作极端有效率，而且用户评论 CVS snapshots趋向于稳定和使用安全。

因为以下理由，我们相信用Spring构建的应用程序是非常易于测试的：

IoC推动了单元测试

应用程序不包括直接使用注入JNDI的J2EE服务的plumbing code，这些代码一般让测试难于进行

Spring bean factories和contexts能够在容器外设置

在容器外可以设置Spring bean factory的能力提供了对开发过程有趣的可选项。在几个使用Spring的web应用中，工作是从定义业务接口和在web容器外集成测试开始的。在业务功能已经足够完整之后，web接口不过是添加在其上的薄薄一层。
谁在使用Spring

虽然相对来说Spring还是一个新的项目，但是我们已经有了一个令人印象深刻并且不断增长的用户群。它们已经有许多产品使用着Spring。用户包括一个主要的全球投资银行（做大型项目的），一些知名的网络公司，几个web开发顾问机构，卫生保健公司，以及学院机构。

许多用户完整地使用Spring，但是一些只单独使用一些组件。例如，大量用户使用我们地JDBC或者其他数据访问功能。
Roadmap

在今年晚些时候我们主要要做的是让Spring发布release 1.0。然而，我们还有一些更长远的目标。

为1.0 final规划地主要改进式源代码级地元数据支持，它主要用于（但不局限于）AOP框架。这将使得C#风格的attribute驱动的事务管理，并且让声明式企业服务在典型应用情况下非常容易配置。Attribute支持将会在Spring的1.0 final release支持中加入，并且设计的是在发布的那个时候能与JSR-175集成。

1.0之后，一些可能的改进地方包括：

通过对我们的JDBC和事务支持的一个相当抽象来支持JMS

支持bean factories的动态重配置

提供web services的能力

IDE和其他工具支持

作为一个敏捷项目，我们主要是受到用户需求的驱动。因而我们不会开发没有一个用户需要的特性，并且我们会仔细倾听来自用户群的声音。
总结

Spring是一个解决了许多在J2EE开发中常见的问题的强大框架。

Spring提供了管理业务对象的一致方法并且鼓励了注入对接口编程而不是对类编程的良好习惯。Spring的架构基础是基于使用JavaBean属性的 Inversion of Control容器。然而，这仅仅是完整图景中的一部分：Spring在使用IoC容器作为构建完关注所有架构层的完整解决方案方面是独一无二的。

Spring提供了唯一的数据访问抽象，包括简单和有效率的JDBC框架，极大的改进了效率并且减少了可能的错误。Spring的数据访问架构还集成了Hibernate和其他O/R mapping解决方案。

Spring还提供了唯一的事务管理抽象，它能够在各种底层事务管理技术，例如JTA或者JDBC纸上提供一个一致的编程模型。

Spring提供了一个用标准Java语言编写的AOP框架，它给POJOs提供了声明式的事务管理和其他企业事务——如果你需要——还能实现你自己的aspects。这个框架足够强大，使得应用程序能够抛开EJB的复杂性，同时享受着和传统EJB相关的关键服务。

Spring还提供了可以和总体的IoC容器集成的强大而灵活的MVC web框架。
更多信息

参见以下资源获得关于Spring的更多信息：

Expert One-on-One J2EE Design and Development（Rod Johnson，Wrox，2002）。虽然Spring在书出版之后已经极大地进步和改进了，它仍然是理解Spring动机的极佳途径。

Spring的主页：http://www.springframework.org。这里包括Javadoc和几个教程。

在Sourceforge上的论坛和下载

Spring用户和Spring开发者的邮件列表

我们正在尽我们可能去改进Spring的文档和示例。我们还为在信件和邮件列表中极好的回复率自豪。我们希望你能快速融入我们的社区！
关于作者

Rod Johnson 作为Java开发者和架构师已经有了7年的经验了并且在J2EE平台出现之初就在其上进行开发了。他是《Expert One- on-One J2EE Design and Development》(Wrox，2002)的作者并且贡献了其他好几本关于J2EE的书。他当前正在为Wiley撰写另外一本有关J2EE架构的书。Rod在两个Java标准委员会服务并且经常师大会发言人。现在他在UK做一个咨询顾问。

lanxin1020 2009-04-07 23:30 发表评论

spring 容器内部工作机制(转)

lanxin1020 — Tue, 07 Apr 2009 15:06:00 GMT

Spring的AbstractApplicationContext是ApplicationContext抽象实现类，该抽象类的refresh()方法定义了Spring容器在加载配置文件后的各项处理过程，这些处理过程清晰刻画了Spring容器启动时所执行的各项操作。下面，我们来看一下refresh()内部定义了哪些执行逻辑：

498)this.style.width=498;" height=224>

1．初始化BeanFactory：根据配置文件实例化BeanFactory，getBeanFactory()方法由具体子类实现。在这一步里，Spring将配置文件的信息装入到容器的Bean定义注册表（BeanDefinitionRegistry）中，但此时Bean还未初始化；
2．调用工厂后处理器：根据反射机制从BeanDefinitionRegistry中找出所有BeanFactoryPostProcessor类型的Bean，并调用其postProcessBeanFactory()接口方法；
3．注册Bean后处理器：根据反射机制从BeanDefinitionRegistry中找出所有BeanPostProcessor类型的Bean，并将它们注册到容器Bean后处理器的注册表中；
4．初始化消息源：初始化容器的国际化信息资源；
5．初始化应用上下文事件广播器；
6．初始化其他特殊的Bean：这是一个钩子方法，子类可以借助这个钩子方法执行一些特殊的操作：如AbstractRefreshableWebApplicationContext就使用该钩子方法执行初始化ThemeSource的操作；
7．注册事件监听器；
8．初始化singleton的Bean：实例化所有singleton的Bean，并将它们放入Spring容器的缓存中；
9．发布上下文刷新事件：创建上下文刷新事件，事件广播器负责将些事件广播到每个注册的事件监听器中。
在第3.4节中，我们观摩了Bean从创建到销毁的生命历程，这些过程都可以在上面的过程中找到对应的步骤。Spring协调多个组件共同完成这个复杂的工程流程，图5-1描述了Spring容器从加载配置文件到创建出一个完整Bean的作业流程以及参与的角色。

498)this.style.width=498;" height=277>

图5-1 IoC的流水线

1．ResourceLoader从存储介质中加载Spring配置文件，并使用Resource表示这个配置文件的资源；
2．BeanDefinitionReader读取Resource所指向的配置文件资源，然后解析配置文件。配置文件中每一个解析成一个BeanDefinition对象，并保存到BeanDefinitionRegistry中；
3．容器扫描BeanDefinitionRegistry中的BeanDefinition，使用Java的反射机制自动识别出Bean工厂后处理器（实现BeanFactoryPostProcessor接口）的Bean，然后调用这些Bean工厂后处理器对BeanDefinitionRegistry中的BeanDefinition进行加工处理。主要完成以下两项工作：
1）对使用到占位符的元素标签进行解析，得到最终的配置值，这意味对一些半成品式的BeanDefinition对象进行加工处理并得到成品的BeanDefinition对象；
2）对BeanDefinitionRegistry中的BeanDefinition进行扫描，通过Java反射机制找出所有属性编辑器的Bean（实现java.beans.PropertyEditor接口的Bean），并自动将它们注册到Spring容器的属性编辑器注册表中（PropertyEditorRegistry）；
4．Spring容器从BeanDefinitionRegistry中取出加工后的BeanDefinition，并调用InstantiationStrategy着手进行Bean实例化的工作；
5．在实例化Bean时，Spring容器使用BeanWrapper对Bean进行封装，BeanWrapper提供了很多以Java反射机制操作Bean的方法，它将结合该Bean的BeanDefinition以及容器中属性编辑器，完成Bean属性的设置工作；
6．利用容器中注册的Bean后处理器（实现BeanPostProcessor接口的Bean）对已经完成属性设置工作的Bean进行后续加工，直接装配出一个准备就绪的Bean。
Spring容器确实堪称一部设计精密的机器，其内部拥有众多的组件和装置。Spring的高明之处在于，它使用众多接口描绘出了所有装置的蓝图，构建好Spring的骨架，继而通过继承体系层层推演，不断丰富，最终让Spring成为有血有肉的完整的框架。所以查看Spring框架的源码时，有两条清晰可见的脉络：
1）接口层描述了容器的重要组件及组件间的协作关系；
2）继承体系逐步实现组件的各项功能。
接口层清晰地勾勒出Spring框架的高层功能，框架脉络呼之欲出。有了接口层抽象的描述后，不但Spring自己可以提供具体的实现，任何第三方组织也可以提供不同实现，可以说Spring完善的接口层使框架的扩展性得到了很好的保证。纵向继承体系的逐步扩展，分步骤地实现框架的功能，这种实现方案保证了框架功能不会堆积在某些类的身上，造成过重的代码逻辑负载，框架的复杂度被完美地分解开了。
Spring组件按其所承担的角色可以划分为两类：
1）物料组件：Resource、BeanDefinition、PropertyEditor以及最终的Bean等，它们是加工流程中被加工、被消费的组件，就像流水线上被加工的物料；
2）加工设备组件：ResourceLoader、BeanDefinitionReader、BeanFactoryPostProcessor、InstantiationStrategy以及BeanWrapper等组件像是流水线上不同环节的加工设备，对物料组件进行加工处理。
我们在第3章中已经介绍了Resource和ResourceLoader这两个组件。在本章中，我们将对其他的组件进行讲解。

lanxin1020 2009-04-07 23:06 发表评论

利用Java的反射与代理实现AOP(转)

lanxin1020 — Mon, 06 Apr 2009 03:50:00 GMT

利用Java的反射与代理实现AOP

一．AOP概述

AOP(Aspect Oriented Programing)，即面向切面编程，它主要用于日志记录、性能统计、安全控制、事务处理、异常处理等方面。它的主要意图就要将日志记录，性能统计，安全控制、事务处理、异常处理等等代码从业务逻辑代码中清楚地划分出来。通过对这些行为的分离，我们希望可以将它们独立地配置到业务逻辑方法中，而要改变这些行为的时候也不需要影响到业务逻辑方法代码。

下面让我们来看一个利用AOP来实现日志记录的例子，在没有使用AOP之前，我们的代码如下面所讲述。

下面这段代码为业务的接口类代码：

package org.amigo.proxy;
/**
* 业务逻辑类接口.
* @author AmigoXie
* Creation date: 2007-10-7 - 上午09:09:53
*/
public interface BusinessObj {
/**
* 执行业务.
*/
    public void process();
}
BusinessObj接口的某个实现类代码如下：
package org.amigo.proxy;
/**
* 业务逻辑对象实现类.
* @author AmigoXie
* Creation date: 2007-10-7 - 上午09:11:49
*/
public class BusinessObjImpl implements BusinessObj {
/**
* 执行业务.
*/
    public void process() {
try {
System.out.println("before process");
System.out.println("执行业务逻辑");
System.out.println("after process");
} catch (Exception e) {
System.err.println("发生异常:" + e.toString());
}
}
}

在上例中我们可以看到，在执行业务方法前、执行业务方法后以及异常发生时的日志记录，我们都是通过在对应的类中写入记录日志的代码来实现的，当有这种日志记录需求的业务逻辑类不断增多时，将会给我们的维护带来很大困难，而且，在上面的例子中，日志代码和业务逻辑代码混合在一起，为日后的维护工作又抹上了一层“恐怖”色彩。

按照AOP的思想，我们首先需要寻找一个切面，在这里我们已经找到，即在业务逻辑执行前后以及异常发生时，进行相应的日志记录。我们需要将这部分日志代码放入一个单独的类中，以便为以后的修改提供方便。

我们在截获某个业务逻辑方法时，可以采用Java的动态代理机制来实现。

二．Java的动态代理机制

代理模式是常用的Java设计模式。代理类主要负责为委托类预处理消息、过滤信息、把消息转发给委托类，以及事后处理信息等。

动态代理类不仅简化了编程工作，而且提高了软件系统的扩展性和可维护性。我们可以通过实现java.lang.reflect.InvocationHandler接口提供一个执行处理器，然后通过java.lang.reflect.Proxy得到一个代理对象，通过这个代理对象来执行业务逻辑方法,在业务逻辑方法被调用的同时，自动调用会执行处理器。
下面让我们来创建一个日志拦截器类LogInterceptor.java文件，该类实现java.lang.reflect.InvocationHandler接口，其内容如下所示：

package org.amigo.proxy;
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;
/**
* 日志拦截器，用来进行日志处理.
* @author AmigoXie
* Creation date: 2007-10-7 - 上午09:31:44
*/
public class LogInterceptor implements InvocationHandler {
private Object delegate;
/**
* 构造函数,设置代理对象.
*/
     public LogInterceptor(Object delegate){
this.delegate = delegate;
}
/**
* 方法的调用.
* @param proxy
* @param method 对应的方法
* @param args 方法的参信息
* @return 返回操作结果对象
* @throws Throwable
*/
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
Object result = null;
try {
System.out.println("before process" + method);
//调用代理对象delegate的method方法，并将args作为参数信息传入
            result = method.invoke(delegate, args);
System.out.println("after process" + method);
} catch (Exception e){
System.err.println("发生异常:" + e.toString());
}
return result;
}
/**
* 测试方法.
* @param args
* @throws Exception
*/
    public static void main(String[] args) throws Exception {
BusinessObj obj = new BusinessObjImpl();
//创建一个日志拦截器
        LogInterceptor interceptor = new LogInterceptor(obj);
//通过Proxy类的newProxyInstance(...)方法来获得动态的代理对象
        BusinessObj proxy = (BusinessObj) Proxy.newProxyInstance(
BusinessObjImpl.class.getClassLoader(),
BusinessObjImpl.class.getInterfaces(),
interceptor);
//执行动态代理对象的业务逻辑方法
        proxy.process();
}
}

此时还需要对BusinessObj的实现类BusinessObjImpl类进行修改，去掉其日志记录等内容，修改后的文件如下：

package org.amigo.proxy;
/**
* 业务逻辑对象实现类.
* @author AmigoXie
* Creation date: 2007-10-7 - 上午09:11:49
*/
public class BusinessObjImpl implements BusinessObj {
/**
* 执行业务.
*/
    public void process() {
System.out.println("执行业务逻辑");
}
}

运行LogInterceptor类我们可以发现，它实现了前面所需要的功能，但是很好的将业务逻辑方法的代码和日志记录的代码分离开来，并且所有的业务处理对象都可以利用该类来完成日志的记录，防止了重复代码的出现，增加了程序的可扩展性和可维护性，从而提高了代码的质量。那么Spring中的AOP的实现是怎么样的呢？接着让我们来对Spring的AOP进行探讨，了解其内部实现原理。

三．Spring中AOP的模拟实现

在学习了Java的动态代理机制后，我们在本节中将学习Java的动态代理机制在Spring中的应用。首先我们创建一个名为AopHandler的类，该类可生成代理对象，同时可以根据设置的前置或后置处理对象分别在方法执行前后执行一些另外的操作，该类的内容如下所示：

package org.amigo.proxy;
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;
/**
* AOP处理器.
* @author AmigoXie
* Creation date: 2007-10-7 - 上午10:13:28
*/
public class AopHandler implements InvocationHandler {
//需要代理的目标对象  
    private Object target;
//方法前置顾问  
    Advisor beforeAdvisor;
//方法后置顾问
    Advisor afterAdvisor;
/**
* 设置代理目标对象，并生成动态代理对象.
* @param target 代理目标对象
* @return 返回动态代理对象
*/
    public Object setObject(Object target) {
//设置代理目标对象
        this.target = target;
//根据代理目标对象生成动态代理对象
        Object obj = Proxy.newProxyInstance(
target.getClass().getClassLoader(),
target.getClass().getInterfaces(), this);
return obj;
}
/**
* 若定义了前置处理，则在方法执行前执行前置处理，
* 若定义了后置处理，则在方法调用后调用后置处理.
* @param proxy 代理对象
* @param method 调用的业务方法
* @param args 方法的参数
* @return 返回结果信息
* @throws Throwable
*/
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
//进行业务方法的前置处理
        if (beforeAdvisor != null) {
beforeAdvisor.doInAdvisor(proxy, method, args);
}
//执行业务方法
        Object result = method.invoke(target, args);
//进行业务方法的后置处理
        if (afterAdvisor != null) {
afterAdvisor.doInAdvisor(proxy, method, args);
}
//返回结果对象
        return result;
}
/**
* 设置方法的前置顾问.
* @param advisor 方法的前置顾问
*/
    public void setBeforeAdvisor(Advisor advisor) {
this.beforeAdvisor = advisor;
}
/**
* 设置方法的后置顾问.
* @param advisor 方法的后置顾问
*/
    public void setAfterAdvisor(Advisor advisor) {
this.afterAdvisor = advisor;
}
}

在上类中，前置和后置顾问对象都继承Advisor接口，接下来让我们来看看顾问接口类的内容，该类定义了doInAdvisor(Object proxy, Method method, Object[] args)方法，如下所示：

package org.amigo.proxy;
import java.lang.reflect.Method;
/**
*
* 顾问接口类.
* @author AmigoXie
* Creation date: 2007-10-7 - 上午10:21:18
*/
public interface Advisor {
/**
* 所做的操作.
*/
    public void doInAdvisor(Object proxy, Method method, Object[] args);
}
BeforeMethodAdvisor和AfterMethodAdvisor都实现了Advisor接口，分别为方法的前置顾问和后置顾问类。
BeforeMethodAdvisor.java文件（前置顾问类）的内容如下所示：
package org.amigo.proxy;
import java.lang.reflect.Method;
/**
*
* 方法前置顾问，它完成方法的前置操作.
* @author AmigoXie
* Creation date: 2007-10-7 - 上午10:19:57
*/
public class BeforeMethodAdvisor implements Advisor {
/**
* 在方法执行前所进行的操作.
*/
    public void doInAdvisor(Object proxy, Method method, Object[] args) {
System.out.println("before process " + method);
}
}
AfterMethodAdvisor.java文件（后置顾问类）的内容如下所示：
package org.amigo.proxy;
import java.lang.reflect.Method;
/**
*
* 方法的后置顾问，它完成方法的后置操作.
* @author AmigoXie
* Creation date: 2007-10-7 - 上午10:20:43
*/
public class AfterMethodAdvisor implements Advisor {
/**
* 在方法执行后所进行的操作.
*/
    public void doInAdvisor(Object proxy, Method method, Object[] args) {
System.out.println("after process " + method);
}
}

这两个类分别在方法执行前和方法执行后做一些额外的操作。

对于在配置文件中对某个bean配置前置或后置处理器，我们可以在bean中增加两个属性aop和aopType，aop的值为对应的前置顾问类或后置顾问类的名称，aopType用于指明该顾问类为前置还是后置顾问，为before时表示为前置处理器，为after时表示为后置处理器，这时候我们需要修改上一篇文章中的BeanFactory.java这个文件，添加其对aop和aopType的处理，修改后的该文件内容如下：

package org.amigo.proxy;
import java.io.InputStream;
import java.lang.reflect.Method;
import java.util.HashMap;
import java.util.Iterator;
import java.util.Map;
import org.dom4j.Attribute;
import org.dom4j.Document;
import org.dom4j.Element;
import org.dom4j.io.SAXReader;
/**
* bean工厂类.
* @author AmigoXie
* Creation date: 2007-10-7 - 下午04:04:34
*/
public class BeanFactory {
private Map<String, Object> beanMap = new HashMap<String, Object>();
/**
* bean工厂的初始化.
* @param xml xml配置文件
*/
    public void init(String xml) {
try {
//读取指定的配置文件
            SAXReader reader = new SAXReader();
ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
InputStream ins = classLoader.getResourceAsStream(xml);
Document doc = reader.read(ins);
Element root = doc.getRootElement();
Element foo;
//创建AOP处理器
            AopHandler aopHandler = new AopHandler();
//遍历bean
            for (Iterator i = root.elementIterator("bean"); i.hasNext();) {
foo = (Element) i.next();
//获取bean的属性id、class、aop以及aopType
                Attribute id = foo.attribute("id");
Attribute cls = foo.attribute("class");
Attribute aop = foo.attribute("aop");
Attribute aopType = foo.attribute("aopType");
//配置了aop和aopType属性时，需进行拦截操作
                if (aop != null && aopType != null) {
//根据aop字符串获取对应的类
                    Class advisorCls = Class.forName(aop.getText());
//创建该类的对象
                    Advisor advisor = (Advisor) advisorCls.newInstance();
//根据aopType的类型来设置前置或后置顾问
                    if ("before".equals(aopType.getText())) {
aopHandler.setBeforeAdvisor(advisor);
} else if ("after".equals(aopType.getText())) {
aopHandler.setAfterAdvisor(advisor);
}
}
//利用Java反射机制，通过class的名称获取Class对象
                Class bean = Class.forName(cls.getText());
//获取对应class的信息
                java.beans.BeanInfo info = java.beans.Introspector.getBeanInfo(bean);
//获取其属性描述
                java.beans.PropertyDescriptor pd[] = info.getPropertyDescriptors();
//设置值的方法
                Method mSet = null;
//创建一个对象
                Object obj = bean.newInstance();
//遍历该bean的property属性
                for (Iterator ite = foo.elementIterator("property"); ite.hasNext();) {
Element foo2 = (Element) ite.next();
//获取该property的name属性
                    Attribute name = foo2.attribute("name");
String value = null;
//获取该property的子元素value的值
                    for(Iterator ite1 = foo2.elementIterator("value"); ite1.hasNext();) {
Element node = (Element) ite1.next();
value = node.getText();
break;
}
for (int k = 0; k < pd.length; k++) {
if (pd[k].getName().equalsIgnoreCase(name.getText())) {
mSet = pd[k].getWriteMethod();
//利用Java的反射极致调用对象的某个set方法，并将值设置进去
                            mSet.invoke(obj, value);
}
}
}
//为对象增加前置或后置顾问
                obj = (Object) aopHandler.setObject(obj);
//将对象放入beanMap中，其中key为id值，value为对象
                beanMap.put(id.getText(), obj);
}
} catch (Exception e) {
System.out.println(e.toString());
}
}
/**
* 通过bean的id获取bean的对象.
* @param beanName bean的id
* @return 返回对应对象
*/
    public Object getBean(String beanName) {
Object obj = beanMap.get(beanName);
return obj;
}
/**
* 测试方法.
* @param args
*/
    public static void main(String[] args) {
BeanFactory factory = new BeanFactory();
factory.init("config.xml");
BusinessObj obj = (BusinessObj) factory.getBean("businessObj");
obj.process();
}
}

观察此类我们可以发现，该类添加了对bean元素的aop和aopType属性的处理。编写完该文件后，我们还需要修改src目录下的配置文件：config.xml文件，在该文件中添加名为businessObj的bean，我们为其配置了aop和aopType属性，增加了方法的前置顾问。增加的部分为：

此时运行BeanFactory.java这个类文件，运行结果如下：

before process public abstract void org.amigo.proxy.BusinessObj.process()

执行业务逻辑

由运行结果可以看出，前置处理已经生效。

本节中的例子只是实现了Spring的AOP一小部分功能，即为某个bean添加前置或后置处理，在Spring中，考虑的比这多很多，例如，为多个bean配置动态代理等等。但是究其根源，Spring中AOP的实现，是基于Java中无比强大的反射和动态代理机制。

四．总结

本文讲述了AOP的概念等信息，并详细讲解了Java的动态代理机制，接着又通过一个简单的实例讲解了Spring中AOP的模拟实现，使得读者能够更好地学习Java的反射和代理机制。

通过这两篇文章，使得我们能够更加深入地理解Java的反射和动态代理机制，同时对Spring中盛行的IOC和AOP的后台实现原理有了更加清晰的理解，Java的反射和动态代理机制的强大功能在这两篇文章中可见一斑。有兴趣的朋友可以通过学习Spring框架的源码来进一步的理解Java的反射和动态代理机制，从而在实际的开发工作中更好地理解

lanxin1020 2009-04-06 11:50 发表评论

利用java的反射实现IOC(转)

lanxin1020 — Mon, 06 Apr 2009 03:43:00 GMT

摘要: spring IOC 机制模拟实现收藏在Java中，其反射和动态代理机制极其强大，我们可以通过其反射机制在运行时获取信息。而代理是一种基本的设计模式，它是一种为了提供额外的或不同的操作而插入到真实对象中的某个对象。而Java的动态代理在代理上更进一步，既能动态的创建代理对象，又... 阅读全文

lanxin1020 2009-04-06 11:43 发表评论

工厂模式与 ioc(转)

lanxin1020 — Sun, 05 Apr 2009 16:13:00 GMT

Spring的模块化是很强的，各个功能模块都是独立的，我们可以选择的使用。这一章先从Spring的IoC开始。所谓IoC就是一个用XML来定义生成对象的模式，我们看看如果来使用的。

　　 数据模型

　　 1、如下图所示有三个类，Human（人类）是接口，Chinese（中国人）是一个子类，American（美国人）是另外一个子类。

源代码如下：

java 代码

package cn.com.chengang.spring;
public interface Human {
void eat();
void walk();
}
package cn.com.chengang.spring;
public class Chinese implements Human {
/* （非 Javadoc）
* @see cn.com.chengang.spring.Human#eat()
*/
public void eat() {
System.out.println("中国人对吃很有一套");
}
/* （非 Javadoc）
* @see cn.com.chengang.spring.Human#walk()
*/
public void walk() {
System.out.println("中国人行如飞");
}
}
package cn.com.chengang.spring;
public class American implements Human {
/* （非 Javadoc）
* @see cn.com.chengang.spring.Human#eat()
*/
public void eat() {
System.out.println("美国人主要以面包为主");
}
/* （非 Javadoc）
* @see cn.com.chengang.spring.Human#walk()
*/
public void walk() {
System.out.println("美国人以车代步，有四肢退化的趋势");
}
}

2、对以上对象采用工厂模式的用法如下

　　创建一个工厂类Factory，如下。这个工厂类里定义了两个字符串常量，所标识不同的人种。getHuman方法根据传入参数的字串，来判断要生成什么样的人种。

java 代码

package cn.com.chengang.spring;
public class Factory {
public final static String CHINESE = "Chinese";
public final static String AMERICAN = "American";
public Human getHuman(String ethnic) {
if (ethnic.equals(CHINESE))
return new Chinese();
else if (ethnic.equals(AMERICAN))
return new American();
else
throw new IllegalArgumentException("参数(人种)错误");
}
}

下面是一个测试的程序，使用工厂方法来得到了不同的“人种对象”，并执行相应的方法。

java 代码

package cn.com.chengang.spring;
public class ClientTest {
public static void main(String[] args) {
Human human = null;
human = new Factory().getHuman(Factory.CHINESE);
human.eat();
human.walk();
human = new Factory().getHuman(Factory.AMERICAN);
human.eat();
human.walk();
}
}

3、采用Spring的IoC的用法如下：

　　在项目根目录下创建一个bean.xml文件

xml 代码

＜?xml version="1.0" encoding="UTF-8"?＞
＜!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd"＞
＜beans＞
＜bean id="Chinese" class="cn.com.chengang.spring.Chinese"/＞
＜bean id="American" class="cn.com.chengang.spring.American"/＞
＜/beans＞

修改ClientTest程序如下：

java 代码

package cn.com.chengang.spring;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.FileSystemXmlApplicationContext;
public class ClientTest {
public final static String CHINESE = "Chinese";
public final static String AMERICAN = "American";
public static void main(String[] args) {
// Human human = null;
// human = new Factory().getHuman(Factory.CHINESE);
// human.eat();
// human.walk();
// human = new Factory().getHuman(Factory.AMERICAN);
// human.eat();
// human.walk();
ApplicationContext ctx = new FileSystemXmlApplicationContext("bean.xml");
Human human = null;
human = (Human) ctx.getBean(CHINESE);
human.eat();
human.walk();
human = (Human) ctx.getBean(AMERICAN);
human.eat();
human.walk();
}
}

从这个程序可以看到，ctx就相当于原来的Factory工厂，原来的Factory就可以删除掉了。然后又把Factory里的两个常量移到了ClientTest类里，整个程序结构基本一样。

　　再回头看原来的bean.xml文件的这一句：

＜bean id="Chinese" class="cn.com.chengang.spring.Chinese"/＞

　　 id就是ctx.getBean的参数值，一个字符串。class就是一个类（包名＋类名）。然后在ClientTest类里获得Chinese对象就是这么一句

human = (Human) ctx.getBean(CHINESE);

　　因为getBean方法返回的是Object类型，所以前面要加一个类型转换。

　　总结

　　（1）也许有人说，IoC和工厂模式不是一样的作用吗，用IoC好象还麻烦一点。

　　举个例子，如果用户需求发生变化，要把Chinese类修改一下。那么前一种工厂模式，就要更改Factory类的方法，并且重新编译布署。而IoC只需要将class属性改变一下，并且由于IoC利用了Java反射机制，这些对象是动态生成的，这时我们就可以热插拨Chinese对象（不必把原程序停止下来重新编译布署）

　　（2）也许有人说，即然IoC这么好，那么我把系统所有对象都用IoC方式来生成。

　　注意，IoC的灵活性是有代价的：设置步骤麻烦、生成对象的方式不直观、反射比正常生成对象在效率上慢一点。因此使用IoC要看有没有必要，我认为比较通用的判断方式是：用到工厂模式的地方都可以考虑用IoC模式。

　　（3）在上面的IoC的方式里，还有一些可以变化的地方。比如，bean.xml不一定要放在项目录下，也可以放在其他地方，比如cn.com.chengang.spring包里。不过在使用时也要变化一下，如下所示：

new FileSystemXmlApplicationContext("src/cn/com/chengang/spring/bean.xml");

　　另外，bean.xml也可以改成其他名字。这样我们在系统中就可以分门别类的设置不同的bean.xml。

　　（4）关于IoC的低侵入性。

　　什么是低侵入性？如果你用过Struts或EJB就会发现，要继承一些接口或类，才能利用它们的框架开发。这样，系统就被绑定在Struts、EJB上了，对系统的可移植性产生不利的影响。如果代码中很少涉及某一个框架的代码，那么这个框架就可以称做是一个低侵入性的框架。

　　 Spring的侵入性很低，Humen.java、Chinese.java等几个类都不必继承什么接口或类。但在ClientTest里还是有一些Spring的影子：FileSystemXmlApplicationContext类和ctx.getBean方式等。
现在，低侵入性似乎也成了判定一个框架的实现技术好坏的标准之一。

　　（5）关于bean.xml的用法

　　 bean.xml的用法还有很多，其中内容是相当丰富的。假设Chinese类里有一个humenName属性（姓名），那么原的bean.xml修改如下。此后生成Chinese对象时，“陈刚”这个值将自动设置到Chinese类的humenName属性中。而且由于singleton为true这时生成Chinese对象将采用单例模式，系统仅存在一个Chinese对象实例。

＜?xml version="1.0" encoding="UTF-8"?＞
＜!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd"＞
＜beans＞
＜bean id="Chinese" class="cn.com.chengang.spring.Chinese" singleton="true"＞
＜property name="humenName"＞
＜value＞陈刚＜/value＞
＜/property＞
＜/bean＞
＜bean id="American" class="cn.com.chengang.spring.American"/＞
＜/beans＞

　　关于bean.xml的其它用法，不再详细介绍了，大家自己拿Spring的文档一看就明白了。

　Spring能有效地组织J2EE应用各层的对象。不管是控制层的Action对象，还是业务层的Service对象，还是持久层的DAO对象，都可在Spring的管理下有机地协调、运行。Spring将各层的对象以松耦合的方式组织在一起，Action对象无须关心Service对象的具体实现，Service对象无须关心持久层对象的具体实现，各层对象的调用完全面向接口。当系统需要重构时，代码的改写量将大大减少。

　　上面所说的一切都得宜于Spring的核心机制，依赖注入。依赖注入让bean与bean之间以配置文件组织在一起，而不是以硬编码的方式耦合在一起。理解依赖注入

　　依赖注入(Dependency Injection)和控制反转(Inversion of Control)是同一个概念。具体含义是:当某个角色(可能是一个Java实例，调用者)需要另一个角色(另一个Java实例，被调用者)的协助时，在传统的程序设计过程中，通常由调用者来创建被调用者的实例。但在Spring里，创建被调用者的工作不再由调用者来完成，因此称为控制反转;创建被调用者实例的工作通常由Spring容器来完成，然后注入调用者，因此也称为依赖注入。

　　不管是依赖注入，还是控制反转，都说明Spring采用动态、灵活的方式来管理各种对象。对象与对象之间的具体实现互相透明。在理解依赖注入之前，看如下这个问题在各种社会形态里如何解决:一个人(Java实例，调用者)需要一把斧子(Java实例，被调用者)。

　　(1)原始社会里，几乎没有社会分工。需要斧子的人(调用者)只能自己去磨一把斧子(被调用者)。对应的情形为:Java程序里的调用者自己创建被调用者。

　　(2)进入工业社会，工厂出现。斧子不再由普通人完成，而在工厂里被生产出来，此时需要斧子的人(调用者)找到工厂，购买斧子，无须关心斧子的制造过程。对应Java程序的简单工厂的设计模式。

　　(3)进入“按需分配”社会，需要斧子的人不需要找到工厂，坐在家里发出一个简单指令:需要斧子。斧子就自然出现在他面前。对应Spring的依赖注入。

　　第一种情况下，Java实例的调用者创建被调用的Java实例，必然要求被调用的Java类出现在调用者的代码里。无法实现二者之间的松耦合。

　　第二种情况下，调用者无须关心被调用者具体实现过程，只需要找到符合某种标准(接口)的实例，即可使用。此时调用的代码面向接口编程，可以让调用者和被调用者解耦，这也是工厂模式大量使用的原因。但调用者需要自己定位工厂，调用者与特定工厂耦合在一起。

　　第三种情况下，调用者无须自己定位工厂，程序运行到需要被调用者时，系统自动提供被调用者实例。事实上，调用者和被调用者都处于Spring的管理下，二者之间的依赖关系由Spring提供。

　　所谓依赖注入，是指程序运行过程中，如果需要调用另一个对象协助时，无须在代码中创建被调用者，而是依赖于外部的注入。Spring的依赖注入对调用者和被调用者几乎没有任何要求，完全支持对POJO之间依赖关系的管理。依赖注入通常有两种:

　　·设值注入。

　　·构造注入。
.......

lanxin1020 2009-04-06 00:13 发表评论

AOP 动态代理模式(转)

lanxin1020 — Sun, 05 Apr 2009 14:40:00 GMT

摘要: 最简单的解决方案我们先写一个接口IHello.java代码如下: 1package sinosoft.dj.aop.staticaop; 2 3public interface IHello { 4 /** *//** 5&nbs... 阅读全文

lanxin1020 2009-04-05 22:40 发表评论

整合 Struts 和 Spring

lanxin1020 — Sun, 05 Apr 2009 02:17:00 GMT

摘要: Struts Recipes 的合著者 George Franciscus 将介绍另一个重大的 Struts 整合窍门 —— 这次是将 Struts 应用程序导入 Spring 框架。请跟随 George，他将向您展示如何改变 Struts 动作，使得管理 Struts 动作就像管理 Spring beans 那... 阅读全文

lanxin1020 2009-04-05 10:17 发表评论

三种整合 Struts 应用程序与 Spring 的方式(转)

lanxin1020 — Sun, 05 Apr 2009 01:37:00 GMT

三种整合 Struts 应用程序与 Spring 的方式

Struts Recipes 的合著者 George Franciscus 将介绍另一个重大的 Struts 整合窍门 —— 这次是将 Struts 应用程序导入 Spring 框架。请跟随 George，他将向您展示如何改变 Struts 动作，使得管理 Struts 动作就像管理 Spring beans 那样。结果是一个增强的 web 框架，这个框架可以方便地利用 Spring AOP 的优势。

您肯定已经听说过控制反转 (IOC) 设计模式，因为很长一段时间以来一直在流传关于它的信息。如果您在任何功能中使用过 Spring 框架，那么您就知道其原理的作用。在本文中，我利用这一原理把一个 Struts 应用程序注入 Spring 框架，您将亲身体会到 IOC 模式的强大。

将一个 Struts 应用程序整合进 Spring 框架具有多方面的优点。首先，Spring 是为解决一些关于 JEE 的真实世界问题而设计的，比如复杂性、低性能和可测试性，等等。第二，Spring 框架包含一个 AOP 实现，允许您将面向方面技术应用于面向对象的代码。第三，一些人可能会说 Spring 框架只有处理 Struts 比 Struts 处理自己好。但是这是观点问题，我演示三种将 Struts 应用程序整合到 Spring 框架的方法后，具体由您自己决定使用哪一种。

我所演示的方法都是执行起来相对简单的，但是它们却具有明显不同的优点。我为每一种方法创建了一个独立而可用的例子，这样您就可以完全理解每种方法。请参阅下载部分获得完整例子源代码。请参阅参考资料，下载 Struts MVC 和 Spring 框架。

为什么 Spring 这么了不起？

Spring 的创立者 Rod Johnson 以一种批判的眼光看待 Java™ 企业软件开发，并且提议很多企业难题都能够通过战略地使用 IOC 模式（也称作依赖注入）来解决。当 Rod 和一个具有奉献精神的开放源码开发者团队将这个理论应用于实践时，结果就产生了 Spring 框架。简言之，Spring 是一个轻型的容器，利用它可以使用一个外部 XML 配置文件方便地将对象连接在一起。每个对象都可以通过显示一个 JavaBean 属性收到一个到依赖对象的引用，留给您的简单任务就只是在一个 XML 配置文件中把它们连接好。

IOC 和 Spring

IOC 是一种使应用程序逻辑外在化的设计模式，所以它是被注入而不是被写入客户机代码中。将 IOC 与接口编程应用结合，就像 Spring 框架那样，产生了一种架构，这种架构能够减少客户机对特定实现逻辑的依赖。请参阅参考资料了解更多关于 IOC 和 Spring 的信息。

依赖注入是一个强大的特性，但是 Spring 框架能够提供更多特性。Spring 支持可插拔的事务管理器，可以给您的事务处理提供更广泛的选择范围。它集成了领先的持久性框架，并且提供一个一致的异常层次结构。Spring 还提供了一种使用面向方面代码代替正常的面向对象代码的简单机制。

Spring AOP 允许您使用拦截器 在一个或多个执行点上拦截应用程序逻辑。加强应用程序在拦截器中的日志记录逻辑会产生一个更可读的、实用的代码基础，所以拦截器广泛用于日志记录。您很快就会看到，为了处理横切关注点，Spring AOP 发布了它自己的拦截器，您也可以编写您自己的拦截器。

整合 Struts 和 Spring

与 Struts 相似，Spring 可以作为一个 MVC 实现。这两种框架都具有自己的优点和缺点，尽管大部分人同意 Struts 在 MVC 方面仍然是最好的。很多开发团队已经学会在时间紧迫的时候利用 Struts 作为构造高品质软件的基础。Struts 具有如此大的推动力，以至于开发团队宁愿整合 Spring 框架的特性，而不愿意转换成 Spring MVC。没必要进行转换对您来说是一个好消息。Spring 架构允许您将 Struts 作为 Web 框架连接到基于 Spring 的业务和持久层。最后的结果就是现在一切条件都具备了。

在接下来的小窍门中，您将会了解到三种将 Struts MVC 整合到 Spring 框架的方法。我将揭示每种方法的缺陷并且对比它们的优点。一旦您了解到所有三种方法的作用，我将会向您展示一个令人兴奋的应用程序，这个程序使用的是这三种方法中我最喜欢的一种。

三个小窍门

接下来的每种整合技术（或者窍门）都有自己的优点和特点。我偏爱其中的一种，但是我知道这三种都能够加深您对 Struts 和 Spring 的理解。在处理各种不同情况的时候，这将给您提供一个广阔的选择范围。方法如下：

使用 Spring 的 ActionSupport 类整合 Structs
使用 Spring 的 DelegatingRequestProcessor 覆盖 Struts 的 RequestProcessor
将 Struts Action 管理委托给 Spring 框架

装载应用程序环境

无论您使用哪种技术，都需要使用 Spring 的 ContextLoaderPlugin 为 Struts 的 ActionServlet 装载 Spring 应用程序环境。就像添加任何其他插件一样，简单地向您的 struts-config.xml 文件添加该插件，如下所示：

前面已经提到过，在下载部分，您能够找到这三个完全可使用的例子的完整源代码。每个例子都为一个书籍搜索应用程序提供一种不同的 Struts 和 Spring 的整合方法。您可以在这里看到例子的要点，但是您也可以下载应用程序以查看所有的细节。

窍门 1. 使用 Spring 的 ActionSupport

手动创建一个 Spring 环境是一种整合 Struts 和 Spring 的最直观的方式。为了使它变得更简单，Spring 提供了一些帮助。为了方便地获得 Spring 环境，org.springframework.web.struts.ActionSupport 类提供了一个 getWebApplicationContext() 方法。您所做的只是从 Spring 的 ActionSupport 而不是 Struts Action 类扩展您的动作，如清单 1 所示：

清单 1. 使用 ActionSupport 整合 Struts

package ca.nexcel.books.actions;
                        import java.io.IOException;
                        import javax.servlet.ServletException;
                        import javax.servlet.http.HttpServletRequest;
                        import javax.servlet.http.HttpServletResponse;
                        import org.apache.struts.action.ActionError;
                        import org.apache.struts.action.ActionErrors;
                        import org.apache.struts.action.ActionForm;
                        import org.apache.struts.action.ActionForward;
                        import org.apache.struts.action.ActionMapping;
                        import org.apache.struts.action.DynaActionForm;
                        import org.springframework.context.ApplicationContext;
                        import org.springframework.web.struts.ActionSupport;
                        import ca.nexcel.books.beans.Book;
                        import ca.nexcel.books.business.BookService;
                        public class SearchSubmit extends ActionSupport {   |(1)
                        public ActionForward execute(
                        ActionMapping mapping,
                        ActionForm form,
                        HttpServletRequest request,
                        HttpServletResponse response)
                        throws IOException, ServletException {
                        DynaActionForm searchForm = (DynaActionForm) form;
                        String isbn = (String) searchForm.get("isbn");
                        //the old fashion way
                        //BookService bookService = new BookServiceImpl();
                        ApplicationContext ctx =
                        getWebApplicationContext();    |(2)
                        BookService bookService =
                        (BookService) ctx.getBean("bookService");   |(3)
                        Book book = bookService.read(isbn.trim());
                        if (null == book) {
                        ActionErrors errors = new ActionErrors();
                        errors.add(ActionErrors.GLOBAL_ERROR,new ActionError
                        ("message.notfound"));
                        saveErrors(request, errors);
                        return mapping.findForward("failure") ;
                        }
                        request.setAttribute("book", book);
                        return mapping.findForward("success");
                        }
                        }

让我们快速思考一下这里到底发生了什么。在 (1) 处，我通过从 Spring 的 ActionSupport 类而不是 Struts 的 Action 类进行扩展，创建了一个新的 Action。在 (2) 处，我使用 getWebApplicationContext() 方法获得一个 ApplicationContext。为了获得业务服务，我使用在 (2) 处获得的环境在 (3) 处查找一个 Spring bean。

这种技术很简单并且易于理解。不幸的是，它将 Struts 动作与 Spring 框架耦合在一起。如果您想替换掉 Spring，那么您必须重写代码。并且，由于 Struts 动作不在 Spring 的控制之下，所以它不能获得 Spring AOP 的优势。当使用多重独立的 Spring 环境时，这种技术可能有用，但是在大多数情况下，这种方法不如另外两种方法合适。

窍门 2. 覆盖 RequestProcessor

将 Spring 从 Struts 动作中分离是一个更巧妙的设计选择。分离的一种方法是使用 org.springframework.web.struts.DelegatingRequestProcessor 类来覆盖 Struts 的 RequestProcessor 处理程序，如清单 2 所示：

清单 2. 通过 Spring 的 DelegatingRequestProcessor 进行整合

我利用了标记来用 DelegatingRequestProcessor 覆盖默认的 Struts RequestProcessor。下一步是在我的 Spring 配置文件中注册该动作，如清单 3 所示：

清单 3. 在 Spring 配置文件中注册一个动作

注意：在 (1) 处，我使用名称属性注册了一个 bean，以匹配 struts-config 动作映射名称。SearchSubmit 动作揭示了一个 JavaBean 属性，允许 Spring 在运行时填充属性，如清单 4 所示：

清单 4. 具有 JavaBean 属性的 Struts 动作

package ca.nexcel.books.actions;
                        import java.io.IOException;
                        import javax.servlet.ServletException;
                        import javax.servlet.http.HttpServletRequest;
                        import javax.servlet.http.HttpServletResponse;
                        import org.apache.struts.action.Action;
                        import org.apache.struts.action.ActionError;
                        import org.apache.struts.action.ActionErrors;
                        import org.apache.struts.action.ActionForm;
                        import org.apache.struts.action.ActionForward;
                        import org.apache.struts.action.ActionMapping;
                        import org.apache.struts.action.DynaActionForm;
                        import ca.nexcel.books.beans.Book;
                        import ca.nexcel.books.business.BookService;
                        public class SearchSubmit extends Action {
                        private BookService bookService;
                        public BookService getBookService() {
                        return bookService;
                        }
                        public void setBookService(BookService bookService) { | (1)
                        this.bookService = bookService;
                        }
                        public ActionForward execute(
                        ActionMapping mapping,
                        ActionForm form,
                        HttpServletRequest request,
                        HttpServletResponse response)
                        throws IOException, ServletException {
                        DynaActionForm searchForm = (DynaActionForm) form;
                        String isbn = (String) searchForm.get("isbn");
                        Book book = getBookService().read(isbn.trim());  |(2)
                        if (null == book) {
                        ActionErrors errors = new ActionErrors();
                        errors.add(ActionErrors.GLOBAL_ERROR,new ActionError("message.notfound"));
                        saveErrors(request, errors);
                        return mapping.findForward("failure") ;
                        }
                        request.setAttribute("book", book);
                        return mapping.findForward("success");
                        }
                        }

在清单 4 中，您可以了解到如何创建 Struts 动作。在 (1) 处，我创建了一个 JavaBean 属性。DelegatingRequestProcessor自动地配置这种属性。这种设计使 Struts 动作并不知道它正被 Spring 管理，并且使您能够利用 Sping 的动作管理框架的所有优点。由于您的 Struts 动作注意不到 Spring 的存在，所以您不需要重写您的 Struts 代码就可以使用其他控制反转容器来替换掉 Spring。

DelegatingRequestProcessor 方法的确比第一种方法好，但是仍然存在一些问题。如果您使用一个不同的 RequestProcessor，则需要手动整合 Spring 的 DelegatingRequestProcessor。添加的代码会造成维护的麻烦并且将来会降低您的应用程序的灵活性。此外，还有过一些使用一系列命令来代替 Struts RequestProcessor 的传闻。这种改变将会对这种解决方法的使用寿命造成负面的影响。

窍门 3. 将动作管理委托给 Spring

一个更好的解决方法是将 Strut 动作管理委托给 Spring。您可以通过在 struts-config 动作映射中注册一个代理来实现。代理负责在 Spring 环境中查找 Struts 动作。由于动作在 Spring 的控制之下，所以它可以填充动作的 JavaBean 属性，并为应用诸如 Spring 的 AOP 拦截器之类的特性带来了可能。

清单 5 中的 Action 类与清单 4 中的相同。但是 struts-config 有一些不同：

清单 5. Spring 整合的委托方法


                        
                        
                        
                        
                        
                        
                        
                        
                        
                        
                        
                        
                        
                        
                        
                        |(1)
                        input="/searchEntry.do"
                        validate="true"
                        name="searchForm">

清单 5 是一个典型的 struts-config.xml 文件，只有一个小小的差别。它注册 Spring 代理类的名称，而不是声明动作的类名，如（1）处所示。DelegatingActionProxy 类使用动作映射名称查找 Spring 环境中的动作。这就是我们使用 ContextLoaderPlugIn 声明的环境。

将一个 Struts 动作注册为一个 Spring bean 是非常直观的，如清单 6 所示。我利用动作映射使用标记的名称属性（在这个例子中是 "/searchSubmit"）简单地创建了一个 bean。这个动作的 JavaBean 属性像任何 Spring bean 一样被填充：

清单 6. 在 Spring 环境中注册一个 Struts 动作

动作委托的优点

动作委托解决方法是这三种方法中最好的。Struts 动作不了解 Spring，不对代码作任何改变就可用于非 Spring 应用程序中。RequestProcessor 的改变不会影响它，并且它可以利用 Spring AOP 特性的优点。

动作委托的优点不止如此。一旦让 Spring 控制您的 Struts 动作，您就可以使用 Spring 给动作补充更强的活力。例如，没有 Spring 的话，所有的 Struts 动作都必须是线程安全的。如果您设置标记的 singleton 属性为“false”，那么不管用何种方法，您的应用程序都将在每一个请求上有一个新生成的动作对象。您可能不需要这种特性，但是把它放在您的工具箱中也很好。您也可以利用 Spring 的生命周期方法。例如，当实例化 Struts 动作时，标记的 init-method 属性被用于运行一个方法。类似地，在从容器中删除 bean 之前，destroy-method 属性执行一个方法。这些方法是管理昂贵对象的好办法，它们以一种与 Servlet 生命周期相同的方式进行管理。

拦截 Struts

前面提到过，通过将 Struts 动作委托给 Spring 框架而整合 Struts 和 Spring 的一个主要的优点是：您可以将 Spring 的 AOP 拦截器应用于您的 Struts 动作。通过将 Spring 拦截器应用于 Struts 动作，您可以用最小的代价处理横切关注点。

虽然 Spring 提供很多内置拦截器，但是我将向您展示如何创建自己的拦截器并把它应用于一个 Struts 动作。为了使用拦截器，您需要做三件事：

创建拦截器。
注册拦截器。
声明在何处拦截代码。

这看起来非常简单的几句话却非常强大。例如，在清单 7 中，我为 Struts 动作创建了一个日志记录拦截器。这个拦截器在每个方法调用之前打印一句话：

清单 7. 一个简单的日志记录拦截器

package ca.nexcel.books.interceptors;
                        import org.springframework.aop.MethodBeforeAdvice;
                        import java.lang.reflect.Method;
                        public class LoggingInterceptor implements MethodBeforeAdvice {
                        public void before(Method method, Object[] objects, Object o) throws Throwable {
                        System.out.println("logging before!");
                        }
                        }

这个拦截器非常简单。before() 方法在拦截点中每个方法之前运行。在本例中，它打印出一句话，其实它可以做您想做的任何事。下一步就是在 Spring 配置文件中注册这个拦截器，如清单 8 所示：

清单 8. 在 Spring 配置文件中注册拦截器


                        
                        
                        
                        
                        
                        
                        
                        
                        
                         |(1)
                        
                         |(2)
                        
                        /searchSubmit|(3)
                        
                        
                        
                        logger |(4)

您可能已经注意到了，清单 8 扩展了清单 6 中所示的应用程序以包含一个拦截器。具体细节如下：

在 (1) 处，我注册了这个拦截器。
在 (2) 处，我创建了一个 bean 名称自动代理，它描述如何应用拦截器。还有其他的方法定义拦截点，但是这种方法常见而简便。
在 (3) 处，我将 Struts 动作注册为将被拦截的 bean。如果您想要拦截其他的 Struts 动作，则只需要在 "beanNames" 下面创建附加的标记。
在 (4) 处，当拦截发生时，我执行了在 (1) 处创建的拦截器 bean 的名称。这里列出的所有拦截器都应用于“beanNames”。

就是这样。就像这个例子所展示的，将您的 Struts 动作置于 Spring 框架的控制之下，为处理您的 Struts 应用程序提供了一系列全新的选择。在本例中，使用动作委托可以轻松地利用 Spring 拦截器提高 Struts 应用程序中的日志记录能力。

结束语

在本文中，您已经学习了将 Struts 动作整合到 Spring 框架中的三种窍门。使用 Spring 的 ActionSupport 来整合 Struts（第一种窍门中就是这样做的）简单而快捷，但是会将 Struts 动作与 Spring 框架耦合在一起。如果您需要将应用程序移植到一个不同的框架，则需要重写代码。第二种解决方法通过委托 RequestProcessor 巧妙地解开代码的耦合，但是它的可扩展性不强，并且当 Struts 的 RequestProcessor 变成一系列命令时，这种方法就持续不了很长时间。第三种方法是这三种方法中最好的：将 Struts 动作委托给 Spring 框架可以使代码解耦，从而使您可以在您的 Struts 应用程序中利用 Spring 的特性（比如日志记录拦截器）。

lanxin1020 2009-04-05 09:37 发表评论

Spring 的优秀工具类盘点2(转)

lanxin1020 — Sun, 05 Apr 2009 00:45:00 GMT

特殊字符转义

由于 Web 应用程序需要联合使用到多种语言，每种语言都包含一些特殊的字符，对于动态语言或标签式的语言而言，如果需要动态构造语言的内容时，一个我们经常会碰到的问题就是特殊字符转义的问题。下面是 Web 开发者最常面对需要转义的特殊字符类型：

HTML 特殊字符；
JavaScript 特殊字符；
SQL 特殊字符；

如果不对这些特殊字符进行转义处理，则不但可能破坏文档结构，还可以引发潜在的安全问题。Spring 为 HTML 和 JavaScript 特殊字符提供了转义操作工具类，它们分别是 HtmlUtils 和 JavaScriptUtils。

HTML 特殊字符转义

HTML 中 <，>，& 等字符有特殊含义，它们是 HTML 语言的保留字，因此不能直接使用。使用这些个字符时，应使用它们的转义序列：

&：&
" ："
< ：<
> ：>

由于 HTML 网页本身就是一个文本型结构化文档，如果直接将这些包含了 HTML 特殊字符的内容输出到网页中，极有可能破坏整个 HTML 文档的结构。所以，一般情况下需要对动态数据进行转义处理，使用转义序列表示 HTML 特殊字符。下面的 JSP 网页将一些变量动态输出到 HTML 网页中：

清单 1. 未进行 HTML 特殊字符转义处理网页

            <%@ page language="java" contentType="text/html; charset=utf-8"%>
            <%!
            String userName = "

"; String address = " \" type=\"button"; %> ①

姓名：	<%=userName%>
年龄：	28

②

在 ① 和 ② 处，我们未经任何转义处理就直接将变量输出到 HTML 网页中，由于这些变量可能包含一些特殊的 HTML 的字符，它们将可能破坏整个 HTML 文档的结构。我们可以从以上 JSP 页面的一个具体输出中了解这一问题：

① 破坏了


            
            姓名：

的结构

年龄：

② 将本来是输入框组件偷梁换柱为按钮组件

融合动态数据后的 HTML 网页已经面目全非，首先 ① 处的

结构被包含 HTML 特殊字符的 userName 变量截断了，造成其后的

代码变成无效的内容；其次，② 处被动态数据改换为按钮类型的组件（type="button"）。为了避免这一问题，我们需要事先对可能破坏 HTML 文档结构的动态数据进行转义处理。Spring 为我们提供了一个简单适用的 HTML 特殊字符转义工具类，它就是 HtmlUtils。下面，我们通过一个简单的例子了解 HtmlUtils 的具体用法：

清单 2. HtmpEscapeExample

            package com.baobaotao.escape;
            import org.springframework.web.util.HtmlUtils;
            public class HtmpEscapeExample {
            public static void main(String[] args) {
            String specialStr = "test1;test2";
            String str1 = HtmlUtils.htmlEscape(specialStr); ①转换为HTML转义字符表示
            System.out.println(str1);
            String str2 = HtmlUtils.htmlEscapeDecimal(specialStr); ②转换为数据转义表示
            System.out.println(str2);
            String str3 = HtmlUtils.htmlEscapeHex(specialStr); ③转换为十六进制数据转义表示
            System.out.println(str3);
            ④下面对转义后字符串进行反向操作
            System.out.println(HtmlUtils.htmlUnescape(str1));
            System.out.println(HtmlUtils.htmlUnescape(str2));
            System.out.println(HtmlUtils.htmlUnescape(str3));
            }
            }

HTML 不但可以使用通用的转义序列表示 HTML 特殊字符，还可以使用以 # 为前缀的数字序列表示 HTML 特殊字符，它们在最终的显示效果上是一样的。HtmlUtils 提供了三个转义方法：

方法	说明
`static String htmlEscape(String input)`	将 HTML 特殊字符转义为 HTML 通用转义序列；
`static String htmlEscapeDecimal(String input)`	将 HTML 特殊字符转义为带 # 的十进制数据转义序列；
`static String htmlEscapeHex(String input)`	将 HTML 特殊字符转义为带 # 的十六进制数据转义序列；

此外，HtmlUtils 还提供了一个能够将经过转义内容还原的方法：htmlUnescape(String input)，它可以还原以上三种转义序列的内容。运行以上代码，您将可以看到以下的输出：

str1:<div id="testDiv">test1;test2</div>
            str2:<div id="testDiv">test1;test2</div>
            str3:<div id="testDiv">test1;test2</div>
            test1;test2
            test1;test2
            test1;test2

您只要使用 HtmlUtils 对代码清单 1 的 userName 和 address 进行转义处理，最终输出的 HTML 页面就不会遭受破坏了。

JavaScript 特殊字符转义

JavaScript 中也有一些需要特殊处理的字符，如果直接将它们嵌入 JavaScript 代码中，JavaScript 程序结构将会遭受破坏，甚至被嵌入一些恶意的程序。下面列出了需要转义的特殊 JavaScript 字符：

' ：\'
" ：\"
\ ：\\
走纸换页： \f
换行：\n
换栏符：\t
回车：\r
回退符：\b



我们通过一个具体例子演示动态变量是如何对 JavaScript 程序进行破坏的。假设我们有一个 JavaScript 数组变量，其元素值通过一个 Java List 对象提供，下面是完成这一操作的 JSP 代码片断：

清单 3. jsTest.jsp：未对 JavaScript 特殊字符进行处理

            <%@ page language="java" contentType="text/html; charset=utf-8"%>
            
            <%
            List textList = new ArrayList();
            textList.add("\";alert();j=\"");
            %>

当客户端调用这个 JSP 页面后，将得到以下的 HTML 输出页面：

由于包含 JavaScript 特殊字符的 Java 变量直接合并到 JavaScript 代码中，我们本来期望 ① 处所示部分是一个普通的字符串，但结果变成了一段 JavaScript 代码，网页将弹出一个 alert 窗口。想像一下如果粗体部分的字符串是“";while(true)alert();j="”时会产生什么后果呢？

因此，如果网页中的 JavaScript 代码需要通过拼接 Java 变量动态产生时，一般需要对变量的内容进行转义处理，可以通过 Spring 的 JavaScriptUtils 完成这件工作。下面，我们使用 JavaScriptUtils 对以上代码进行改造：

<%@ page language="java" contentType="text/html; charset=utf-8"%>
            
            
            <%
            List textList = new ArrayList();
            textList.add("\";alert();j=\"");
            %>

通过转义处理后，这个 JSP 页面输出的结果网页的 JavaScript 代码就不会产生问题了：

SQL特殊字符转义

应该说，您即使没有处理 HTML 或 JavaScript 的特殊字符，也不会带来灾难性的后果，但是如果不在动态构造 SQL 语句时对变量中特殊字符进行处理，将可能导致程序漏洞、数据盗取、数据破坏等严重的安全问题。网络中有大量讲解 SQL 注入的文章，感兴趣的读者可以搜索相关的资料深入研究。

虽然 SQL 注入的后果很严重，但是只要对动态构造的 SQL 语句的变量进行特殊字符转义处理，就可以避免这一问题的发生了。来看一个存在安全漏洞的经典例子：

SELECT COUNT(userId)
            FROM t_user
            WHERE userName='"+userName+"' AND password ='"+password+"';

以上 SQL 语句根据返回的结果数判断用户提供的登录信息是否正确，如果 userName 变量不经过特殊字符转义处理就直接合并到 SQL 语句中，黑客就可以通过将 userName 设置为 “1' or '1'='1”绕过用户名/密码的检查直接进入系统了。

所以除非必要，一般建议通过 PreparedStatement 参数绑定的方式构造动态 SQL 语句，因为这种方式可以避免 SQL 注入的潜在安全问题。但是往往很难在应用中完全避免通过拼接字符串构造动态 SQL 语句的方式。为了防止他人使用特殊 SQL 字符破坏 SQL 的语句结构或植入恶意操作，必须在变量拼接到 SQL 语句之前对其中的特殊字符进行转义处理。Spring 并没有提供相应的工具类，您可以通过 jakarta commons lang 通用类包中（spring/lib/jakarta-commons/commons-lang.jar）的 StringEscapeUtils 完成这一工作：

清单 4. SqlEscapeExample

            package com.baobaotao.escape;
            import org.apache.commons.lang.StringEscapeUtils;
            public class SqlEscapeExample {
            public static void main(String[] args) {
            String userName = "1' or '1'='1";
            String password = "123456";
            userName = StringEscapeUtils.escapeSql(userName);
            password = StringEscapeUtils.escapeSql(password);
            String sql = "SELECT COUNT(userId) FROM t_user WHERE userName='"
            + userName + "' AND password ='" + password + "'";
            System.out.println(sql);
            }
            }

事实上，StringEscapeUtils 不但提供了 SQL 特殊字符转义处理的功能，还提供了 HTML、XML、JavaScript、Java 特殊字符的转义和还原的方法。如果您不介意引入 jakarta commons lang 类包，我们更推荐您使用 StringEscapeUtils 工具类完成特殊字符转义处理的工作。

回页首

方法入参检测工具类

Web 应用在接受表单提交的数据后都需要对其进行合法性检查，如果表单数据不合法，请求将被驳回。类似的，当我们在编写类的方法时，也常常需要对方法入参进行合法性检查，如果入参不符合要求，方法将通过抛出异常的方式拒绝后续处理。举一个例子：有一个根据文件名获取输入流的方法：InputStream getData(String file)，为了使方法能够成功执行，必须保证 file 入参不能为 null 或空白字符，否则根本无须进行后继的处理。这时方法的编写者通常会在方法体的最前面编写一段对入参进行检测的代码，如下所示：

public InputStream getData(String file) {
            if (file == null || file.length() == 0|| file.replaceAll("\\s", "").length() == 0) {
            throw new IllegalArgumentException("file入参不是有效的文件地址");
            }
            …
            }

类似以上检测方法入参的代码是非常常见，但是在每个方法中都使用手工编写检测逻辑的方式并不是一个好主意。阅读 Spring 源码，您会发现 Spring 采用一个 org.springframework.util.Assert 通用类完成这一任务。

Assert 翻译为中文为“断言”，使用过 JUnit 的读者都熟知这个概念，它断定某一个实际的运行值和预期想一样，否则就抛出异常。Spring 对方法入参的检测借用了这个概念，其提供的 Assert 类拥有众多按规则对方法入参进行断言的方法，可以满足大部分方法入参检测的要求。这些断言方法在入参不满足要求时就会抛出 IllegalArgumentException。下面，我们来认识一下 Assert 类中的常用断言方法：

断言方法	说明
`notNull(Object object)`	当 object 不为 null 时抛出异常，notNull(Object object, String message) 方法允许您通过 message 定制异常信息。和 notNull() 方法断言规则相反的方法是 isNull(Object object)/isNull(Object object, String message)，它要求入参一定是 null；
`isTrue(boolean expression) / isTrue(boolean expression, String message)`	当 expression 不为 true 抛出异常；
`notEmpty(Collection collection) / notEmpty(Collection collection, String message)`	当集合未包含元素时抛出异常。notEmpty(Map map) / notEmpty(Map map, String message) 和 notEmpty(Object[] array, String message) / notEmpty(Object[] array, String message) 分别对 Map 和 Object[] 类型的入参进行判断；
`hasLength(String text) / hasLength(String text, String message)`	当 text 为 null 或长度为 0 时抛出异常；
`hasText(String text) / hasText(String text, String message)`	text 不能为 null 且必须至少包含一个非空格的字符，否则抛出异常；
`isInstanceOf(Class clazz, Object obj) / isInstanceOf(Class type, Object obj, String message)`	如果 obj 不能被正确造型为 clazz 指定的类将抛出异常；
`isAssignable(Class superType, Class subType) / isAssignable(Class superType, Class subType, String message)`	subType 必须可以按类型匹配于 superType，否则将抛出异常；

使用 Assert 断言类可以简化方法入参检测的代码，如 InputStream getData(String file) 在应用 Assert 断言类后，其代码可以简化为以下的形式：

public InputStream getData(String file){
            Assert.hasText(file,"file入参不是有效的文件地址");
            ① 使用 Spring 断言类进行方法入参检测
            …
            }

可见使用 Spring 的 Assert 替代自编码实现的入参检测逻辑后，方法的简洁性得到了不少的提高。Assert 不依赖于 Spring 容器，您可以大胆地在自己的应用中使用这个工具类。

回页首

小结

本文介绍了一些常用的 Spring 工具类，其中大部分 Spring 工具类不但可以在基于 Spring 的应用中使用，还可以在其它的应用中使用。

对于 Web 应用来说，由于有很多关联的脚本代码，如果这些代码通过拼接字符串的方式动态产生，就需要对动态内容中特殊的字符进行转义处理，否则就有可能产生意想不到的后果。Spring 为此提供了 HtmlUtils 和 JavaScriptUtils 工具类，只要将动态内容在拼接之前使用工具类进行转义处理，就可以避免类似问题的发生了。如果您不介意引入一个第三方类包，那么 jakarta commons lang 通用类包中的 StringEscapeUtils 工具类可能更加适合，因为它提供了更加全面的转义功能。

最后我们还介绍了 Spring 的 Assert 工具类，Assert 工具类是通用性很强的工具类，它使用面向对象的方式解决方法入参检测的问题，您可以在自己的应用中使用 Assert 对方法入参进行检查。

lanxin1020 2009-04-05 08:45 发表评论

Spring 的优秀工具类盘点1(转)

lanxin1020 — Sun, 05 Apr 2009 00:44:00 GMT

Spring 不但提供了一个功能全面的应用开发框架，本身还拥有众多可以在程序编写时直接使用的工具类，您不但可以在 Spring 应用中使用这些工具类，也可以在其它的应用中使用，这些工具类中的大部分是可以在脱离 Spring 框架时使用的。了解 Spring 中有哪些好用的工具类并在程序编写时适当使用，将有助于提高开发效率、增强代码质量。

在这个分为两部分的文章中，我们将从众多的 Spring 工具类中遴选出那些好用的工具类介绍给大家。第 1 部分将介绍与文件资源操作和 Web 相关的工具类。在第 2 部分中将介绍特殊字符转义和方法入参检测工具类。

文件资源操作

文件资源的操作是应用程序中常见的功能，如当上传一个文件后将其保存在特定目录下，从指定地址加载一个配置文件等等。我们一般使用 JDK 的 I/O 处理类完成这些操作，但对于一般的应用程序来说，JDK 的这些操作类所提供的方法过于底层，直接使用它们进行文件操作不但程序编写复杂而且容易产生错误。相比于 JDK 的 File，Spring 的 Resource 接口（资源概念的描述接口）抽象层面更高且涵盖面更广，Spring 提供了许多方便易用的资源操作工具类，它们大大降低资源操作的复杂度，同时具有更强的普适性。这些工具类不依赖于 Spring 容器，这意味着您可以在程序中象一般普通类一样使用它们。

加载文件资源

Spring 定义了一个 org.springframework.core.io.Resource 接口，Resource 接口是为了统一各种类型不同的资源而定义的，Spring 提供了若干 Resource 接口的实现类，这些实现类可以轻松地加载不同类型的底层资源，并提供了获取文件名、URL 地址以及资源内容的操作方法。

访问文件资源

假设有一个文件地位于 Web 应用的类路径下，您可以通过以下方式对这个文件资源进行访问：

通过 FileSystemResource 以文件系统绝对路径的方式进行访问；
通过 ClassPathResource 以类路径的方式进行访问；
通过 ServletContextResource 以相对于Web应用根目录的方式进行访问。

相比于通过 JDK 的 File 类访问文件资源的方式，Spring 的 Resource 实现类无疑提供了更加灵活的操作方式，您可以根据情况选择适合的 Resource 实现类访问资源。下面，我们分别通过 FileSystemResource 和 ClassPathResource 访问同一个文件资源：

清单 1. FileSourceExample

package com.baobaotao.io;
            import java.io.IOException;
            import java.io.InputStream;
            import org.springframework.core.io.ClassPathResource;
            import org.springframework.core.io.FileSystemResource;
            import org.springframework.core.io.Resource;
            public class FileSourceExample {
            public static void main(String[] args) {
            try {
            String filePath =
            "D:/masterSpring/chapter23/webapp/WEB-INF/classes/conf/file1.txt";
            // ① 使用系统文件路径方式加载文件
            Resource res1 = new FileSystemResource(filePath);
            // ② 使用类路径方式加载文件
            Resource res2 = new ClassPathResource("conf/file1.txt");
            InputStream ins1 = res1.getInputStream();
            InputStream ins2 = res2.getInputStream();
            System.out.println("res1:"+res1.getFilename());
            System.out.println("res2:"+res2.getFilename());
            } catch (IOException e) {
            e.printStackTrace();
            }
            }
            }

在获取资源后，您就可以通过 Resource 接口定义的多个方法访问文件的数据和其它的信息：如您可以通过 getFileName() 获取文件名，通过 getFile() 获取资源对应的 File 对象，通过 getInputStream() 直接获取文件的输入流。此外，您还可以通过 createRelative(String relativePath) 在资源相对地址上创建新的资源。

在 Web 应用中，您还可以通过 ServletContextResource 以相对于 Web 应用根目录的方式访问文件资源，如下所示：

<%@ page language="java" contentType="text/html; charset=utf-8" pageEncoding="utf-8"%>
            
            
            <%
            // ① 注意文件资源地址以相对于 Web 应用根路径的方式表示
            Resource res3 = new ServletContextResource(application,
            "/WEB-INF/classes/conf/file1.txt");
            out.print(res3.getFilename());
            %>

对于位于远程服务器（Web 服务器或 FTP 服务器）的文件资源，您则可以方便地通过 UrlResource 进行访问。

为了方便访问不同类型的资源，您必须使用相应的 Resource 实现类，是否可以在不显式使用 Resource 实现类的情况下，仅根据带特殊前缀的资源地址直接加载文件资源呢？Spring 提供了一个 ResourceUtils 工具类，它支持“classpath:”和“file:”的地址前缀，它能够从指定的地址加载文件资源，请看下面的例子：

清单 2. ResourceUtilsExample

package com.baobaotao.io;
            import java.io.File;
            import org.springframework.util.ResourceUtils;
            public class ResourceUtilsExample {
            public static void main(String[] args) throws Throwable{
            File clsFile = ResourceUtils.getFile("classpath:conf/file1.txt");
            System.out.println(clsFile.isFile());
            String httpFilePath = "file:D:/masterSpring/chapter23/src/conf/file1.txt";
            File httpFile = ResourceUtils.getFile(httpFilePath);
            System.out.println(httpFile.isFile());
            }
            }

ResourceUtils 的 getFile(String resourceLocation) 方法支持带特殊前缀的资源地址，这样，我们就可以在不和 Resource 实现类打交道的情况下使用 Spring 文件资源加载的功能了。

本地化文件资源

本地化文件资源是一组通过本地化标识名进行特殊命名的文件，Spring 提供的 LocalizedResourceHelper 允许通过文件资源基名和本地化实体获取匹配的本地化文件资源并以 Resource 对象返回。假设在类路径的 i18n 目录下，拥有一组基名为 message 的本地化文件资源，我们通过以下实例演示获取对应中国大陆和美国的本地化文件资源：

清单 3. LocaleResourceTest

package com.baobaotao.io;
            import java.util.Locale;
            import org.springframework.core.io.Resource;
            import org.springframework.core.io.support.LocalizedResourceHelper;
            public class LocaleResourceTest {
            public static void main(String[] args) {
            LocalizedResourceHelper lrHalper = new LocalizedResourceHelper();
            // ① 获取对应美国的本地化文件资源
            Resource msg_us = lrHalper.findLocalizedResource("i18n/message", ".properties",
            Locale.US);
            // ② 获取对应中国大陆的本地化文件资源
            Resource msg_cn = lrHalper.findLocalizedResource("i18n/message", ".properties",
            Locale.CHINA);
            System.out.println("fileName(us):"+msg_us.getFilename());
            System.out.println("fileName(cn):"+msg_cn.getFilename());
            }
            }

虽然 JDK 的 java.util.ResourceBundle 类也可以通过相似的方式获取本地化文件资源，但是其返回的是 ResourceBundle 类型的对象。如果您决定统一使用 Spring 的 Resource 接表征文件资源，那么 LocalizedResourceHelper 就是获取文件资源的非常适合的帮助类了。

文件操作

在使用各种 Resource 接口的实现类加载文件资源后，经常需要对文件资源进行读取、拷贝、转存等不同类型的操作。您可以通过 Resource 接口所提供了方法完成这些功能，不过在大多数情况下，通过 Spring 为 Resource 所配备的工具类完成文件资源的操作将更加方便。

文件内容拷贝

第一个我们要认识的是 FileCopyUtils，它提供了许多一步式的静态操作方法，能够将文件内容拷贝到一个目标 byte[]、String 甚至一个输出流或输出文件中。下面的实例展示了 FileCopyUtils 具体使用方法：

清单 4. FileCopyUtilsExample

package com.baobaotao.io;
            import java.io.ByteArrayOutputStream;
            import java.io.File;
            import java.io.FileReader;
            import java.io.OutputStream;
            import org.springframework.core.io.ClassPathResource;
            import org.springframework.core.io.Resource;
            import org.springframework.util.FileCopyUtils;
            public class FileCopyUtilsExample {
            public static void main(String[] args) throws Throwable {
            Resource res = new ClassPathResource("conf/file1.txt");
            // ① 将文件内容拷贝到一个 byte[] 中
            byte[] fileData = FileCopyUtils.copyToByteArray(res.getFile());
            // ② 将文件内容拷贝到一个 String 中
            String fileStr = FileCopyUtils.copyToString(new FileReader(res.getFile()));
            // ③ 将文件内容拷贝到另一个目标文件
            FileCopyUtils.copy(res.getFile(),
            new File(res.getFile().getParent()+ "/file2.txt"));
            // ④ 将文件内容拷贝到一个输出流中
            OutputStream os = new ByteArrayOutputStream();
            FileCopyUtils.copy(res.getInputStream(), os);
            }
            }

往往我们都通过直接操作 InputStream 读取文件的内容，但是流操作的代码是比较底层的，代码的面向对象性并不强。通过 FileCopyUtils 读取和拷贝文件内容易于操作且相当直观。如在 ① 处，我们通过 FileCopyUtils 的 copyToByteArray(File in) 方法就可以直接将文件内容读到一个 byte[] 中；另一个可用的方法是 copyToByteArray(InputStream in)，它将输入流读取到一个 byte[] 中。

如果是文本文件，您可能希望将文件内容读取到 String 中，此时您可以使用 copyToString(Reader in) 方法，如 ② 所示。使用 FileReader 对 File 进行封装，或使用 InputStreamReader 对 InputStream 进行封装就可以了。

FileCopyUtils 还提供了多个将文件内容拷贝到各种目标对象中的方法，这些方法包括：

方法	说明
`static void copy(byte[] in, File out)`	将 byte[] 拷贝到一个文件中
`static void copy(byte[] in, OutputStream out)`	将 byte[] 拷贝到一个输出流中
`static int copy(File in, File out)`	将文件拷贝到另一个文件中
`static int copy(InputStream in, OutputStream out)`	将输入流拷贝到输出流中
`static int copy(Reader in, Writer out)`	将 Reader 读取的内容拷贝到 Writer 指向目标输出中
`static void copy(String in, Writer out)`	将字符串拷贝到一个 Writer 指向的目标中

在实例中，我们虽然使用 Resource 加载文件资源，但 FileCopyUtils 本身和 Resource 没有任何关系，您完全可以在基于 JDK I/O API 的程序中使用这个工具类。

属性文件操作

我们知道可以通过 java.util.Properties的load(InputStream inStream) 方法从一个输入流中加载属性资源。Spring 提供的 PropertiesLoaderUtils 允许您直接通过基于类路径的文件地址加载属性资源，请看下面的例子：

package com.baobaotao.io;
            import java.util.Properties;
            import org.springframework.core.io.support.PropertiesLoaderUtils;
            public class PropertiesLoaderUtilsExample {
            public static void main(String[] args) throws Throwable {
            // ① jdbc.properties 是位于类路径下的文件
            Properties props = PropertiesLoaderUtils.loadAllProperties("jdbc.properties");
            System.out.println(props.getProperty("jdbc.driverClassName"));
            }
            }

一般情况下，应用程序的属性文件都放置在类路径下，所以 PropertiesLoaderUtils 比之于 Properties#load(InputStream inStream) 方法显然具有更强的实用性。此外，PropertiesLoaderUtils 还可以直接从 Resource 对象中加载属性资源：

方法	说明
`static Properties loadProperties(Resource resource)`	从 Resource 中加载属性
`static void fillProperties(Properties props, Resource resource)`	将 Resource 中的属性数据添加到一个已经存在的 Properties 对象中

特殊编码的资源

当您使用 Resource 实现类加载文件资源时，它默认采用操作系统的编码格式。如果文件资源采用了特殊的编码格式（如 UTF-8），则在读取资源内容时必须事先通过 EncodedResource 指定编码格式，否则将会产生中文乱码的问题。

清单 5. EncodedResourceExample

package com.baobaotao.io;
            import org.springframework.core.io.ClassPathResource;
            import org.springframework.core.io.Resource;
            import org.springframework.core.io.support.EncodedResource;
            import org.springframework.util.FileCopyUtils;
            public class EncodedResourceExample {
            public static void main(String[] args) throws Throwable  {
            Resource res = new ClassPathResource("conf/file1.txt");
            // ① 指定文件资源对应的编码格式（UTF-8）
            EncodedResource encRes = new EncodedResource(res,"UTF-8");
            // ② 这样才能正确读取文件的内容，而不会出现乱码
            String content  = FileCopyUtils.copyToString(encRes.getReader());
            System.out.println(content);
            }
            }

EncodedResource 拥有一个 getResource() 方法获取 Resource，但该方法返回的是通过构造函数传入的原 Resource 对象，所以必须通过 EncodedResource#getReader() 获取应用编码后的 Reader 对象，然后再通过该 Reader 读取文件的内容。

回页首

Web 相关工具类

您几乎总是使用 Spring 框架开发 Web 的应用，Spring 为 Web 应用提供了很多有用的工具类，这些工具类可以给您的程序开发带来很多便利。在这节里，我们将逐一介绍这些工具类的使用方法。

操作 Servlet API 的工具类

当您在控制器、JSP 页面中想直接访问 Spring 容器时，您必须事先获取 WebApplicationContext 对象。Spring 容器在启动时将 WebApplicationContext 保存在 ServletContext的属性列表中，通过 WebApplicationContextUtils 工具类可以方便地获取 WebApplicationContext 对象。

WebApplicationContextUtils

当 Web 应用集成 Spring 容器后，代表 Spring 容器的 WebApplicationContext 对象将以 WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE 为键存放在 ServletContext 属性列表中。您当然可以直接通过以下语句获取 WebApplicationContext：

WebApplicationContext wac = (WebApplicationContext)servletContext.
            getAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE);

但通过位于 org.springframework.web.context.support 包中的 WebApplicationContextUtils 工具类获取 WebApplicationContext 更方便：

WebApplicationContext wac =WebApplicationContextUtils.
            getWebApplicationContext(servletContext);

当 ServletContext 属性列表中不存在 WebApplicationContext 时，getWebApplicationContext() 方法不会抛出异常，它简单地返回 null。如果后续代码直接访问返回的结果将引发一个 NullPointerException 异常，而 WebApplicationContextUtils 另一个 getRequiredWebApplicationContext(ServletContext sc) 方法要求 ServletContext 属性列表中一定要包含一个有效的 WebApplicationContext 对象，否则马上抛出一个 IllegalStateException 异常。我们推荐使用后者，因为它能提前发现错误的时间，强制开发者搭建好必备的基础设施。

WebUtils

位于 org.springframework.web.util 包中的 WebUtils 是一个非常好用的工具类，它对很多 Servlet API 提供了易用的代理方法，降低了访问 Servlet API 的复杂度，可以将其看成是常用 Servlet API 方法的门面类。

下面这些方法为访问 HttpServletRequest 和 HttpSession 中的对象和属性带来了方便：

方法	说明
`Cookie getCookie(HttpServletRequest request, String name)`	获取 HttpServletRequest 中特定名字的 Cookie 对象。如果您需要创建 Cookie， Spring 也提供了一个方便的 CookieGenerator 工具类；
`Object getSessionAttribute(HttpServletRequest request, String name)`	获取 HttpSession 特定属性名的对象，否则您必须通过request.getHttpSession.getAttribute(name) 完成相同的操作；
`Object getRequiredSessionAttribute(HttpServletRequest request, String name)`	和上一个方法类似，只不过强制要求 HttpSession 中拥有指定的属性，否则抛出异常；
`String getSessionId(HttpServletRequest request)`	获取 Session ID 的值；
`void exposeRequestAttributes(ServletRequest request, Map attributes)`	将 Map 元素添加到 ServletRequest 的属性列表中，当请求被导向（forward）到下一个处理程序时，这些请求属性就可以被访问到了；

此外，WebUtils还提供了一些和ServletContext相关的方便方法：

方法	说明
`String getRealPath(ServletContext servletContext, String path)`	获取相对路径对应文件系统的真实文件路径；
`File getTempDir(ServletContext servletContext)`	获取 ServletContex 对应的临时文件地址，它以 File 对象的形式返回。

下面的片断演示了使用 WebUtils 从 HttpSession 中获取属性对象的操作：

protected Object formBackingObject(HttpServletRequest request) throws Exception {
            UserSession userSession = (UserSession) WebUtils.getSessionAttribute(request,
            "userSession");
            if (userSession != null) {
            return new AccountForm(this.petStore.getAccount(
            userSession.getAccount().getUsername()));
            } else {
            return new AccountForm();
            }
            }

Spring 所提供的过滤器和监听器

Spring 为 Web 应用提供了几个过滤器和监听器，在适合的时间使用它们，可以解决一些常见的 Web 应用问题。

延迟加载过滤器

Hibernate 允许对关联对象、属性进行延迟加载，但是必须保证延迟加载的操作限于同一个 Hibernate Session 范围之内进行。如果 Service 层返回一个启用了延迟加载功能的领域对象给 Web 层，当 Web 层访问到那些需要延迟加载的数据时，由于加载领域对象的 Hibernate Session 已经关闭，这些导致延迟加载数据的访问异常。

Spring 为此专门提供了一个 OpenSessionInViewFilter 过滤器，它的主要功能是使每个请求过程绑定一个 Hibernate Session，即使最初的事务已经完成了，也可以在 Web 层进行延迟加载的操作。

OpenSessionInViewFilter 过滤器将 Hibernate Session 绑定到请求线程中，它将自动被 Spring 的事务管理器探测到。所以 OpenSessionInViewFilter 适用于 Service 层使用HibernateTransactionManager 或 JtaTransactionManager 进行事务管理的环境，也可以用于非事务只读的数据操作中。

要启用这个过滤器，必须在 web.xml 中对此进行配置：

…
            
            hibernateFilter
            
            org.springframework.orm.hibernate3.support.OpenSessionInViewFilter
            
            
            
            hibernateFilter
            *.html
            
            …

上面的配置，我们假设使用 .html 的后缀作为 Web 框架的 URL 匹配模式，如果您使用 Struts 等 Web 框架，可以将其改为对应的“*.do”模型。

中文乱码过滤器

在您通过表单向服务器提交数据时，一个经典的问题就是中文乱码问题。虽然我们所有的 JSP 文件和页面编码格式都采用 UTF-8，但这个问题还是会出现。解决的办法很简单，我们只需要在 web.xml 中配置一个 Spring 的编码转换过滤器就可以了：


            
            
            encodingFilter
            
            org.springframework.web.filter.CharacterEncodingFilter ① Spring 编辑过滤器
            
             ② 编码方式
            encoding
            UTF-8
            
             ③ 强制进行编码转换
            forceEncoding
            true
            
            
             ② 过滤器的匹配 URL
            encodingFilter
            *.html

这样所有以 .html 为后缀的 URL 请求的数据都会被转码为 UTF-8 编码格式，表单中文乱码的问题就可以解决了。

请求跟踪日志过滤器

除了以上两个常用的过滤器外，还有两个在程序调试时可能会用到的请求日志跟踪过滤器，它们会将请求的一些重要信息记录到日志中，方便程序的调试。这两个日志过滤器只有在日志级别为 DEBUG 时才会起作用：

方法	说明
`org.springframework.web.filter.ServletContextRequestLoggingFilter`	该过滤器将请求的 URI 记录到 Common 日志中（如通过 Log4J 指定的日志文件）；
`org.springframework.web.filter.ServletContextRequestLoggingFilter`	该过滤器将请求的 URI 记录到 ServletContext 日志中。

以下是日志过滤器记录的请求跟踪日志的片断：

(JspServlet.java:224) -     JspEngine --> /htmlTest.jsp
            (JspServlet.java:225) - 	     ServletPath: /htmlTest.jsp
            (JspServlet.java:226) - 	        PathInfo: null
            (JspServlet.java:227) - 	        RealPath: D:\masterSpring\chapter23\webapp\htmlTest.jsp
            (JspServlet.java:228) - 	      RequestURI: /baobaotao/htmlTest.jsp
            …

通过这个请求跟踪日志，程度调试者可以详细地查看到有哪些请求被调用，请求的参数是什么，请求是否正确返回等信息。虽然这两个请求跟踪日志过滤器一般在程序调试时使用，但是即使程序部署不将其从 web.xml 中移除也不会有大碍，因为只要将日志级别设置为 DEBUG 以上级别，它们就不会输出请求跟踪日志信息了。

转存 Web 应用根目录监听器和 Log4J 监听器

Spring 在 org.springframework.web.util 包中提供了几个特殊用途的 Servlet 监听器，正确地使用它们可以完成一些特定需求的功能。比如某些第三方工具支持通过 ${key} 的方式引用系统参数（即可以通过 System.getProperty() 获取的属性），WebAppRootListener 可以将 Web 应用根目录添加到系统参数中，对应的属性名可以通过名为“webAppRootKey”的 Servlet 上下文参数指定，默认为“webapp.root”。下面是该监听器的具体的配置：

清单 6. WebAppRootListener 监听器配置

…
            
            webAppRootKey
            baobaotao.root ① Web 应用根目录以该属性名添加到系统参数中
            
            …
            ② 负责将 Web 应用根目录以 webAppRootKey 上下文参数指定的属性名添加到系统参数中
            
            
            org.springframework.web.util.WebAppRootListener
            
            
            …

这样，您就可以在程序中通过 System.getProperty("baobaotao.root") 获取 Web 应用的根目录了。不过更常见的使用场景是在第三方工具的配置文件中通过${baobaotao.root} 引用 Web 应用的根目录。比如以下的 log4j.properties 配置文件就通过 ${baobaotao.root} 设置了日志文件的地址：

log4j.rootLogger=INFO,R
            log4j.appender.R=org.apache.log4j.RollingFileAppender
            log4j.appender.R.File=${baobaotao.root}/WEB-INF/logs/log4j.log ① 指定日志文件的地址
            log4j.appender.R.MaxFileSize=100KB
            log4j.appender.R.MaxBackupIndex=1
            log4j.appender.R.layout.ConversionPattern=%d %5p [%t] (%F:%L) - %m%n

另一个专门用于 Log4J 的监听器是 Log4jConfigListener。一般情况下，您必须将 Log4J 日志配置文件以 log4j.properties 为文件名并保存在类路径下。Log4jConfigListener 允许您通过 log4jConfigLocation Servlet 上下文参数显式指定 Log4J 配置文件的地址，如下所示：

① 指定 Log4J 配置文件的地址
            
            log4jConfigLocation
            /WEB-INF/log4j.properties
            
            …
            ② 使用该监听器初始化 Log4J 日志引擎
            
            
            org.springframework.web.util.Log4jConfigListener
            
            
            …

提示

一些Web应用服务器（如 Tomcat）不会为不同的Web应用使用独立的系统参数，也就是说，应用服务器上所有的 Web 应用都共享同一个系统参数对象。这时，您必须通过webAppRootKey 上下文参数为不同Web应用指定不同的属性名：如第一个 Web 应用使用 webapp1.root 而第二个 Web 应用使用 webapp2.root 等，这样才不会发生后者覆盖前者的问题。此外，WebAppRootListener 和 Log4jConfigListener 都只能应用在 Web 应用部署后 WAR 文件会解包的 Web 应用服务器上。一些 Web 应用服务器不会将Web 应用的 WAR 文件解包，整个 Web 应用以一个 WAR 包的方式存在（如 Weblogic），此时因为无法指定对应文件系统的 Web 应用根目录，使用这两个监听器将会发生问题。

Log4jConfigListener 监听器包括了 WebAppRootListener 的功能，也就是说，Log4jConfigListener 会自动完成将 Web 应用根目录以 webAppRootKey 上下文参数指定的属性名添加到系统参数中，所以当您使用 Log4jConfigListener 后，就没有必须再使用 WebAppRootListener了。

Introspector 缓存清除监听器

Spring 还提供了一个名为 org.springframework.web.util.IntrospectorCleanupListener 的监听器。它主要负责处理由 JavaBean Introspector 功能而引起的缓存泄露。IntrospectorCleanupListener 监听器在 Web 应用关闭的时会负责清除 JavaBean Introspector 的缓存，在 web.xml 中注册这个监听器可以保证在 Web 应用关闭的时候释放与其相关的 ClassLoader 的缓存和类引用。如果您使用了 JavaBean Introspector 分析应用中的类，Introspector 缓存会保留这些类的引用，结果在应用关闭的时候，这些类以及Web 应用相关的 ClassLoader 不能被垃圾回收。不幸的是，清除 Introspector 的唯一方式是刷新整个缓存，这是因为没法准确判断哪些是属于本 Web 应用的引用对象，哪些是属于其它 Web 应用的引用对象。所以删除被缓存的 Introspection 会导致将整个 JVM 所有应用的 Introspection 都删掉。需要注意的是，Spring 托管的 Bean 不需要使用这个监听器，因为 Spring 的 Introspection 所使用的缓存在分析完一个类之后会马上从 javaBean Introspector 缓存中清除掉，并将缓存保存在应用程序特定的 ClassLoader 中，所以它们一般不会导致内存资源泄露。但是一些类库和框架往往会产生这个问题。例如 Struts 和 Quartz 的 Introspector 的内存泄漏会导致整个的 Web 应用的 ClassLoader 不能进行垃圾回收。在 Web 应用关闭之后，您还会看到此应用的所有静态类引用，这个错误当然不是由这个类自身引起的。解决这个问题的方法很简单，您仅需在 web.xml 中配置 IntrospectorCleanupListener 监听器就可以了：


            
            org.springframework.web.util.IntrospectorCleanupListener

回页首

小结

本文介绍了一些常用的 Spring 工具类，其中大部分 Spring 工具类不但可以在基于 Spring 的应用中使用，还可以在其它的应用中使用。使用 JDK 的文件操作类在访问类路径相关、Web 上下文相关的文件资源时，往往显得拖泥带水、拐弯抹角，Spring 的 Resource 实现类使这些工作变得轻松了许多。

在 Web 应用中，有时你希望直接访问 Spring 容器，获取容器中的 Bean，这时使用 WebApplicationContextUtils 工具类从 ServletContext 中获取 WebApplicationContext 是非常方便的。WebUtils 为访问 Servlet API 提供了一套便捷的代理方法，您可以通过 WebUtils 更好的访问 HttpSession 或 ServletContext 的信息。

Spring 提供了几个 Servlet 过滤器和监听器，其中 ServletContextRequestLoggingFilter 和 ServletContextRequestLoggingFilter 可以记录请求访问的跟踪日志，你可以在程序调试时使用它们获取请求调用的详细信息。WebAppRootListener 可以将 Web 应用的根目录以特定属性名添加到系统参数中，以便第三方工具类通过 ${key} 的方式进行访问。Log4jConfigListener 允许你指定 Log4J 日志配置文件的地址，且可以在配置文件中通过 ${key} 的方式引用 Web 应用根目录，如果你需要在 Web 应用相关的目录创建日志文件，使用 Log4jConfigListener 可以很容易地达到这一目标。

Web 应用的内存泄漏是最让开发者头疼的问题，虽然不正确的程序编写可能是这一问题的根源，也有可能是一些第三方框架的 JavaBean Introspector 缓存得不到清除而导致的，Spring 专门为解决这一问题配备了 IntrospectorCleanupListener 监听器，它只要简单在 web.xml 中声明该监听器就可以了。

lanxin1020 2009-04-05 08:44 发表评论

配置Spring数据源 (转)

lanxin1020 — Wed, 25 Mar 2009 03:14:00 GMT

配置Spring数据源

配置一个数据源
Spring在第三方依赖包中包含了两个数据源的实现类包，其一是Apache的DBCP，其二是 C3P0。可以在Spring配置文件中利用这两者中任何一个配置数据源。

DBCP数据源
DBCP类包位于 /lib/jakarta-commons/commons-dbcp.jar，DBCP 是一个依赖 Jakarta commons-pool对象池机制的数据库连接池，所以在类路径下还必须包括/lib/jakarta- commons /commons-pool.jar。下面是使用DBCP配置MySql数据源的配置片断：

xml 代码
org.apache.commons.dbcp.BasicDataSource"
        destroy-method="close">




bean>
BasicDataSource提供了close()方法关闭数据源，所以必须设定destroy-method=”close”属性，以便Spring容器关闭时，数据源能够正常关闭。除以上必须的数据源属性外，还有一些常用的属性：
    defaultAutoCommit：设置从数据源中返回的连接是否采用自动提交机制，默认值为 true；
    defaultReadOnly：设置数据源是否仅能执行只读操作，默认值为 false；
    maxActive：最大连接数据库连接数，设置为0时，表示没有限制；
    maxIdle：最大等待连接中的数量，设置为0时，表示没有限制；
    maxWait：最大等待秒数，单位为毫秒，超过时间会报出错误信息；
    validationQuery：用于验证连接是否成功的查询SQL语句，SQL语句必须至少要返回一行数据，如你可以简单地设置为：“select count(*) from user”；
    removeAbandoned：是否自我中断，默认是 false ；
    removeAbandonedTimeout：几秒后数据连接会自动断开，在removeAbandoned为true，提供该值；
    logAbandoned：是否记录中断事件，默认为 false；

C3P0数据源
    C3P0 是一个开放源代码的JDBC数据源实现项目，它在lib目录中与Hibernate一起发布，实现了JDBC3和JDBC2扩展规范说明的 Connection 和Statement 池。C3P0类包位于/lib/c3p0/c3p0-0.9.0.4.jar。下面是使用C3P0配置一个 oracle数据源：

xml 代码
        destroy-method="close">




bean>

ComboPooledDataSource和BasicDataSource一样提供了一个用于关闭数据源的close()方法，这样我们就可以保证Spring容器关闭时数据源能够成功释放。
    C3P0拥有比DBCP更丰富的配置属性，通过这些属性，可以对数据源进行各种有效的控制：
    acquireIncrement：当连接池中的连接用完时，C3P0一次性创建新连接的数目；
    acquireRetryAttempts：定义在从数据库获取新连接失败后重复尝试获取的次数，默认为30；
    acquireRetryDelay：两次连接中间隔时间，单位毫秒，默认为1000；
    autoCommitOnClose：连接关闭时默认将所有未提交的操作回滚。默认为false；
    automaticTestTable： C3P0 将建一张名为Test的空表，并使用其自带的查询语句进行测试。如果定义了这个参数，那么属性preferredTestQuery将被忽略。你不能在这张Test表上进行任何操作，它将中为C3P0测试所用，默认为null；
    breakAfterAcquireFailure：获取连接失败将会引起所有等待获取连接的线程抛出异常。但是数据源仍有效保留，并在下次调   用getConnection()的时候继续尝试获取连接。如果设为true，那么在尝试获取连接失败后该数据源将申明已断开并永久关闭。默认为 false；
    checkoutTimeout：当连接池用完时客户端调用getConnection()后等待获取新连接的时间，超时后将抛出SQLException，如设为0则无限期等待。单位毫秒，默认为0；
    connectionTesterClassName：通过实现ConnectionTester或QueryConnectionTester的类来测试连接，类名需设置为全限定名。默认为 com.mchange.v2.C3P0.impl.DefaultConnectionTester；
    idleConnectionTestPeriod：隔多少秒检查所有连接池中的空闲连接，默认为0表示不检查；
    initialPoolSize：初始化时创建的连接数，应在minPoolSize与maxPoolSize之间取值。默认为3；
    maxIdleTime：最大空闲时间，超过空闲时间的连接将被丢弃。为0或负数则永不丢弃。默认为0；
    maxPoolSize：连接池中保留的最大连接数。默认为15；
    maxStatements：JDBC 的标准参数，用以控制数据源内加载的PreparedStatement数量。但由于预缓存的Statement属于单个Connection而不是整个连接池。所以设置这个参数需要考虑到多方面的因素，如果maxStatements与 maxStatementsPerConnection均为0，则缓存被关闭。默认为0；
    maxStatementsPerConnection：连接池内单个连接所拥有的最大缓存Statement数。默认为0；
    numHelperThreads：C3P0是异步操作的，缓慢的JDBC操作通过帮助进程完成。扩展这些操作可以有效的提升性能，通过多线程实现多个操作同时被执行。默认为3；
    preferredTestQuery：定义所有连接测试都执行的测试语句。在使用连接测试的情况下这个参数能显著提高测试速度。测试的表必须在初始数据源的时候就存在。默认为null；
    propertyCycle：用户修改系统配置参数执行前最多等待的秒数。默认为300；
    testConnectionOnCheckout：因性能消耗大请只在需要的时候使用它。如果设为true那么在每个connection提交的时候都将校验其有效性。建议使用 idleConnectionTestPeriod或automaticTestTable
等方法来提升连接测试的性能。默认为false；
    testConnectionOnCheckin：如果设为true那么在取得连接的同时将校验连接的有效性。默认为false。

读配置文件的方式引用属性：

        class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">

bean>
org.apache.commons.dbcp.BasicDataSource"
        destroy-method="close">




bean>

    在jdbc.properties属性文件中定义属性值：
    jdbc.driverClassName= com.mysql.jdbc.Driver
    jdbc.url= jdbc:mysql://localhost:3309/sampledb
    jdbc.username=root
    jdbc.password=1234
    提示经常有开发者在${xxx}的前后不小心键入一些空格，这些空格字符将和变量合并后作为属性的值。如：的属性配置项，在前后都有空格，被解析后，username的值为“ 1234 ”，这将造成最终的错误，因此需要特别小心。

获取JNDI数据源
    如果应用配置在高性能的应用服务器（如WebLogic或Websphere等）上，我们可能更希望使用应用服务器本身提供的数据源。应用服务器的数据源使用JNDI开放调用者使用，Spring为此专门提供引用JNDI资源的JndiObjectFactoryBean类。下面是一个简单的配置：

xml 代码
org.springframework.jndi.JndiObjectFactoryBean">

bean>

通过jndiName指定引用的JNDI数据源名称。
    Spring 2.0为获取J2EE资源提供了一个jee命名空间，通过jee命名空间，可以有效地简化J2EE资源的引用。下面是使用jee命名空间引用JNDI数据源的配置：

xml 代码
springframework.org/schema/beans
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xmlns:jee=http://www.springframework.org/schema/jee
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://www.springframework.org/schema/jee
http://www.springframework.org/schema/jee /spring-jee-2.0.xsd">
jndi-lookup id="dataSource" jndi-name=" java:comp/env/jdbc/bbt"/>
beans>

Spring的数据源实现类
    Spring 本身也提供了一个简单的数据源实现类DriverManagerDataSource ，它位于 org.springframework.jdbc.datasource包中。这个类实现了javax.sql.DataSource接口，但它并没有提供池化连接的机制，每次调用getConnection()获取新连接时，只是简单地创建一个新的连接。因此，这个数据源类比较适合在单元测试或简单的独立应用中使用，因为它不需要额外的依赖类。
     下面，我们来看一下DriverManagerDataSource的简单使用：当然，我们也可以通过配置的方式直接使用DriverManagerDataSource。

java 代码
DriverManagerDataSource ds = new DriverManagerDataSource ();
ds.setDriverClassName("com.mysql.jdbc.Driver");
ds.setUrl("jdbc:mysql://localhost:3309/sampledb");
ds.setUsername("root");
ds.setPassword("1234");
Connection actualCon = ds.getConnection();

小结

    不管采用何种持久化技术，都需要定义数据源。Spring附带了两个数据源的实现类包，你可以自行选择进行定义。在实际部署时，我们可能会直接采用应用服务器本身提供的数据源，这时，则可以通过JndiObjectFactoryBean或jee命名空间引用JNDI中的数据源。

DBCP与C3PO配置的区别：

C3PO ：

xml 代码



        oracle.jdbc.driver.Oracle


        jdbc:oracle:thin:@10.10.10.6:1521:DataBaseNamevalue>


        testAdmin


        123456



DBCP：

xml 代码
org.apache.commons.dbcp.BasicDataSource" destroy-method="close">

        oracle.jdbc.driver.OracleDriver


        jdbc:oracle:thin:@10.10.10.6:1521:DataBaseNamevalue>


        testAdmin


        123456

lanxin1020 2009-03-25 11:14 发表评论

BlogJava-lanxin1020-随笔分类-spring

Introducing to Spring Framework (转)

spring 容器 内部工作机制(转)

利用Java的反射与代理实现AOP(转)

利用java的反射实现IOC(转)

工厂模式 与 ioc(转)

AOP 动态代理模式(转)

整合 Struts 和 Spring

三种整合 Struts 应用程序与 Spring 的方式(转)

三种整合 Struts 应用程序与 Spring 的方式

Spring 的优秀工具类盘点2(转)

Spring 的优秀工具类盘点1(转)

配置Spring数据源 (转)

配置Spring数据源

spring 容器内部工作机制(转)

工厂模式与 ioc(转)