2.3 Web Context设置

　　对于不依赖于应用服务器的Spring 上下文（Context）设置，通常在应用代码中通过FileSystemXmlApplicationContext或ClasspathXmlApplicationContext来获取。比如使用这样的代码来得到上下文：

ApplicationContext ctx = new FileSystemXmlApplicationContext("config.xml");

　 　但是按照控制反转的原则，应用程序代码应该尽可能少的知道上下文的设置。因此，在基于Spring的Web应用中，这样的代码也可以省去。Spring 可以通过配置让Web容器自动装载上下文配置文件。从本质上讲，Web应用的ServletContext就是Spring用来存放应用上下文的地方。 Spring中与Web Context装载相关的有几个类：

　　1．ContextLoaderListener：一般的应用服务器如WAS都能先装载Listener，如果不是的话，那么只能使用ContextLoaderServlet。

　 　2．ContextLoaderServlet：需要配置＜load-on-startup＞使得它率先装载。真正装载Context的类是 ContextLoader，上面两个类只是两种调用ContextLoader的不同途径。ContextLoader内部实际调用的是 XmlWebApplicationContext，其缺省配置文件为/WEB-INF/applicationContext.xml。

　　如果使用ContextLoaderListener，其在web.xml中的配置一般如下：

＜listener＞ ＜listener-class＞ org.springframework.web.context.ContextLoaderListener ＜/listener-class＞ ＜/listener＞

　　如果使用ContextLoaderServlet，其在web.xml中的配置一般如下：

＜servlet＞ ＜servlet-name＞context＜/servlet-name＞ ＜servlet-class＞ org.springframework.web.context.ContextLoaderServlet ＜/servlet-class＞ ＜load-on-startup＞1＜/load-on-startup＞ ＜/servlet＞

　 　应用本身可能除了基于HTTP的Web渠道之外还通过别的渠道对外提供服务，因此，一个比较好的做法是把展示相关的配置与后面业务处理部分的配置分开。 这样如果更改了应用的访问渠道，只需要修改对应的配置文件即可。因此，Spring提供了一个WebApplicationContext的概念。在 WebApplicationContext中一般包含与Web访问相关的配置定义，包括各种控制动作的定义、界面展示的定义等等。

　　 WebApplicationContext一般由DispatcherServlet来初始化。在上下文层次结构上可以把它看成是 ApplcationContext的子上下文。在缺省的情况下，DispatcherServlet装载的配置文件名称为其Servlet名称- Servlet.xml，但是可以通过contextConfigLocation参数来定制。DispatcherServlet在web.xml中的 定义示例如下：

＜servlet＞ ＜servlet-name＞Dispatcher＜/servlet-name＞ ＜servlet-class＞ org.springframework.web.servlet.DispatcherServlet ＜/servlet-class＞ ＜load-on-startup＞2＜/load-on-startup＞ ＜/servlet＞ ＜init-param＞ ＜param-name＞contextConfigLocation＜/param-name＞ ＜param-value＞/WEB-INF/context/Webcontrollers.xml＜/param-value＞ ＜/init-param＞

　　2.4 数据持久化层

　 　虽然使用J2EE技术的Web应用可以连接多种不同的企业信息系统（EIS），但是毫无疑问数据库是其中最为重要和常见的一种。正因如此，Spring 对数据库访问提供了非常完备的支持。数据访问对象（DAO）模式是J2EE模式中非常重要的一种。它的主要目的是使得持久化层与业务逻辑层分离，从而屏蔽 持久化层的具体实现。我们可以把Spring的DAO支持分为两大类，一是直接基于Spring JDBC模板的数据访问，另一类是基于某种O/R映射框架的数据访问。这里刚好可以使用Spring的控制反转特性，通过外部配置文件来定义DAO接口和 实际实现类之间的关系。Spring框架目前支持的O/R映射框架包括Hibernate、JDO、TopLink、iBATIS等。

　　假设我们定义了一个userDAO。当使用JDBC来实现这个DAO的时候，定义的类可以如下所示：

public class userDAOJDBC extends JdbcDaoSupport implements userDAO{ … }

　　如果使用Hibernate来实现这个DAO的时候，定义的类如下：

public class UserDAOHibernate extends HibernateDaoSupport implements UserDAO { … }

　　Spring对于其它的O/R映射机制都有相应的抽象类供应用使用，比如对于iBATIS有SqlMapClientDaoSupport，对于JDO有JdoDaoSupport等。

　　下面我们看一下如何在Spring的配置文件中定义上述DAO与具体实现的关系。假设我们的userDAO具体实现是通过Hibernate，那么在applicationContext.xml中的一个DAO可以定义如下：

＜bean id="userDAO" class="com.fgw.dao.hibernate.UserDAOHibernate"＞ ＜property name="sessionFactory"＞ ＜ref local="sessionFactory"/＞ ＜/property＞ ＜/bean＞

　 　在这里我们实际DAO接口定义是：com.fgw.dao.UserDAO，而具体实现类为： com.fgw.dao.hibernate.UserDAOHibernate。显然，对于其它DAO的实现，我们只需要在配置文件中修改相应的实现类 （具体实现类当然是比不可少的）和属性即可。比如对于JDBC的DAO实现，属性就定义成相应的数据源。

　　3、Spring与WebSphere应用服务器的配合

　　Spring与底层J2EE应用服务器还是存在一些需要结合的地方，这里给出WAS中的一些结合点。

　　3.1 使用WAS数据源

　 　在Java应用程序中，数据库的连接一般有两种方式来得到。一种是通过java.sql.DriverManager的方式来得到数据库连接。这种方式 不依赖于应用服务的支持，但是也不提供数据库连接池的功能。另外一种方式是通过javax.sql.DataSource的方式来得到数据库连接。在传统 基于J2EE的应用需要通过JNDI来得到数据源（javax.sql.DataSource）对象，然后再通过数据源来得到相应的数据库连接。常见的应 用服务器都支持这种方式，且一般都提供了数据库连接池的支持。虽然说我们一般推荐使用数据库连接池，但是也有一些时候我们需要脱离开应用服务器的环境使用 数据库（比如单元测试，比如应用移植等）。然而应用程序使用这两种方式的时候代码是不一样的，因此只能通过代码来应变。Spring提供了一个统一使用数 据源的解决方案，然后通过控制反转的机制用外部配置文件来指定使用的数据源。这样一方面可以统一这两种得到数据库连接的方式，另一方面也不需要像通常的 J2EE应用通过繁琐的JNDI代码来得到数据源。这样应用程序也就不需要知道使用的何种数据源。

　　Spring提供了一个DriverManagerDataSource类来统一第一种方式的数据源获取。如果使用WAS中的Cloudscape数据库，用外部配置文件可配置如下：

＜bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource"＞ ＜property name="driverClassName"＞ ＜value＞com.ibm.db2j.jdbc.DB2jDriver＜/value＞ ＜/property＞ ＜property name="url"＞ ＜value＞jdbc:db2j:D:\\DBName＜/value＞ ＜/property＞ ＜/bean＞

　　Spring提供了JndiObjectFactoryBean类来支持第二种方式的数据源获取。假设WAS中已经配置好的数据源名称为jdbc /MyDB，那么用外部配置文件可配置如下：

＜bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean"＞ ＜property name="jndiName"＞＜value＞java:comp/env/jdbc/MyDB＜/value＞＜/property＞ ＜/bean＞ 或者 ＜bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean"＞ ＜property name="jndiName"＞＜value＞jdbc/MyDB＜/value＞＜/property＞ ＜property name="resourceRef"＞＜value＞true＜/value＞＜/property＞ ＜/bean＞

　 　从上面配置我们可以得知，通过使用Spring，应用程序能够统一使用不同的数据源实现。如果使用环境发生变化，那么只需要修改Spring的配置文件 即可。对于部署在WAS上的Web应用，在生产环境中推荐使用WAS实现的数据库连接池。一方面是因为连接池实现地比较完善。另一方面，使用WAS提供的 数据库连接池可以很完善地支持JTA事务。

　　3.2 使用WAS的JTA

　　Web应用程序在使用事务的时候常常会涉 及一个事务类型的选择。是选择像JDBC事务这样的本地事务呢还是使用JTA支持的全局事务。这个与应用程序需要涉及到的事务管理器类型和个数密切相关。 Spring本身不支持分布式事务，因此分布式事务需要底层的JTA。但是Spring提供了事务的抽象，即底层真正事务实现可以切换而不影响应用程序代 码。这样应用程序可以依赖于底层WAS，也可以轻易地脱离开应用服务器的环境。这一点与前面数据源的抽象非常类似。

　　WAS本身对于事 务划分有两种支持方式，一种是声明式的，当然这种管理方式需要EJB容器的支持，即所谓的容器管理事务（CMT）。另外一种方式是编程式的，通过程序代码 来直接使用JTA编程接口。Spring对于事务的划分也可以分为声明式和编程式两种方式。对于Spring编程式的事务划分方式，总体上可以分为两大 类。一类是通过直接使用实现PlatformTransactionManager接口的类。另一类是通过使用TransactionTemplate模 板类，模板类的使用可以简化事务控制代码。Spring对于声明式事务划分的支持实际上是利用了它的AOP机制。相对于编程式事务划分，这种基于AOP的 方式比较灵活，而且对代码的侵入性几乎为零。因此，如果没有特殊需要推荐使用这种事务划分方式。基于AOP的常用事务划分方式可以使用 ProxyFactoryBean加TransactionInterceptor方式，或者使用 TransactionPorxyFactoryBean的方式。前一种方式相对比较灵活，而后一种则对使用相对比较简单。

　　无论是哪 一种事务划分方式，底层都需要一个事务管理机制作为支撑。如果是单一的事务资源管理器，那么根据所使用的后台事务管理资源不同的类型，可以选择的 PlatformTransactionManager实现有DataSourceTransactionManager， HibernateTransactionManager， JdoTransactionManager， PersistenceBrokerTransactionManager，和JmsTransactionManager等。无论是单个还是多个事务资 源管理器，都可以使用JtaTransactionManager类。如果使用JtaTransactionManager，那么所有事务管理实际都会委 托给底层应用服务器的JTA实现。

　　例如，如果使用JDBC或iBATIS，那么我们可以使用简单的DataSourceTransactionManager，外部配置文件片断如下：

＜bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager"＞ ＜property name="dataSource"＞ ＜ref local="dataSource" /＞ ＜/property＞ ＜/bean＞

　　如果使用Hibernate，那么我们可以使用HibernateTransactionManager，外部配置文件片断如下：

＜bean id="transactionManager" class="org.springframework.orm.hibernate. HibernateTransactionManager"＞ ＜property name="sessionFactory"＞＜ref local="sessionFactory"/＞＜/property＞ ＜/bean＞

　 　使用WAS的JTA支持，我们只需要把上述对应bean中的class属性改成class属性改为 org.springframework.transaction.jta.JtaTransactionManager，然后再把属性改为 WebSphere对应的TransactionManager，参考如下：

＜bean id="wasTxMgr" class="org.springframework.transaction.jta.WebSphereTransactionManagerFactoryBean"/＞ ＜bean id="transactionManager" class="org.springframework.transaction.jta.JtaTransactionManager"＞ ＜property name="transactionManager"＞ ＜ref local="wasTxMgr"/＞ ＜/property＞ ＜/bean＞

　 　通过采用Spring的事务支持，底层事务采用何种方式的决定就不必在一开始开发就做出决定。因为我们能够通过Spring的外部配置文件来进行切换真 正的事务支持。不过，虽然也有第三方的JTA支持，但是WAS能够提供非常稳定的XA支持，因此推荐使用WAS的JTA，尤其是当应用涉及到分布事务处理 的时候。这样无论应用涉及几个事务资源都可以统一解决。

　　3.3 如何加载Spring的JAR包

　　Spring框 架的核心JAR包是spring.jar，但是根据实际使用情况需要一些扩展JAR包和依赖JAR包。那在WAS中如何处理这些JAR包文件呢？在Web 应用中一个简单而直接的处理方式放是把这些使用到的JAR文件都拷贝到对应的WEB-INF/lib目录下面。这种方法虽然简单，但是当有多个 Spring应用程序的时候这种处理方式就需要在每个应用的WEB-INF/lib目录下都拷贝一份相同的JAR文件。这里可以通过共享库的方式来统一解 决类库共享这个问题。

　　共享库就是WAS专门用来解决不同应用程序之间共享JAR或本地库文件的一种机制。共享库由一个名字、一个 JAVA类路径和/或一个装载JNI库本地库路径组成。它可以分别在单元，节点和服务器级别定义。但是共享库定义了并不意味着它会被装载，只有当这个共享 库与某个应用程序或应用服务器关联之后，它才会被加载。如果一个共享库与一个应用程序关联，那么这个共享库由应用程序类加载器加载。如果一个共享库与应用 服务器关联，那么这个共享库就需要一个专门定义的类加载器来加载。这个类加载器需要用户自己定义。其操作如下：选应用服务器比如server1'类加载器 '新建一个类加载器'加载器与共享库关联。

　　在创建这个类加载器之前一般都需要预先定义好共享库。 根据上面的介绍可知，通过共享库解决Spring应用的JAR包共享问题，主要就是两个步骤。一是，把Spring应用中需要共享的JAR包定义成为一个 共享库。二是，选定相应的WAS服务器实例，把它与上面创建的共享库关联起来。这样此WAS服务器实例上的所有应用都能够使用共享库中定义的JAR包。使 用共享库这种方式的时候要注意理解类的装载次序和方式。如果是这种与WAS服务器实例关联的共享库JAR包，其类加载器在层次结构上在应用程序类加载器上 面，即是它的父加载器。关于WAS的类装载器结构和策略可以进一步参考WAS信息中心。

　　4、结束语

　 　Spring框架的核心内容并不依赖于任何容器，但是显然基于Web的应用是Spring主要的应用类型。了解和使用Spring框架一方面可以简化应 用的开发和测试，另一方也可以加深对J2EE技术的理解。另外轻量级的Web应用开发正在成为一种趋势，因此何乐而不为之。上面所讨论的只是Spring 使用中常见的一些内容，Spring框架自己也正变得越来越复杂。当然，Spring、Hibernate等框架中体现的一些思想也正被JEE 5规范所借鉴，尤其是EJB 3中也有了控制反转的应用和POJO的大量使用。实际上无论是JEE技术标准还是Spring等框架，其目的都是如何简化企业应用的开发，只是作为标准， JEE要考虑的内容更为广泛一些，程度也更为深入一些。（源自：IBM ）