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渠道之外還通過別的渠道對外提供服務，因此，一個比較好的做法是把展示相關的配置與后面業(yè)務處理部分的配置分開。 這樣如果更改了應用的訪問渠道，只需要修改對應的配置文件即可。因此，Spring提供了一個WebApplicationContext的概念。在 WebApplicationContext中一般包含與Web訪問相關的配置定義，包括各種控制動作的定義、界面展示的定義等等。

　　 WebApplicationContext一般由DispatcherServlet來初始化。在上下文層次結構上可以把它看成是 ApplcationContext的子上下文。在缺省的情況下，DispatcherServlet裝載的配置文件名稱為其Servlet名稱- Servlet.xml，但是可以通過contextConfigLocation參數(shù)來定制。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 數(shù)據(jù)持久化層

　 　雖然使用J2EE技術的Web應用可以連接多種不同的企業(yè)信息系統(tǒng)（EIS），但是毫無疑問數(shù)據(jù)庫是其中最為重要和常見的一種。正因如此，Spring 對數(shù)據(jù)庫訪問提供了非常完備的支持。數(shù)據(jù)訪問對象（DAO）模式是J2EE模式中非常重要的一種。它的主要目的是使得持久化層與業(yè)務邏輯層分離，從而屏蔽 持久化層的具體實現(xiàn)。我們可以把Spring的DAO支持分為兩大類，一是直接基于Spring JDBC模板的數(shù)據(jù)訪問，另一類是基于某種O/R映射框架的數(shù)據(jù)訪問。這里剛好可以使用Spring的控制反轉特性，通過外部配置文件來定義DAO接口和 實際實現(xiàn)類之間的關系。Spring框架目前支持的O/R映射框架包括Hibernate、JDO、TopLink、iBATIS等。

　　假設我們定義了一個userDAO。當使用JDBC來實現(xiàn)這個DAO的時候，定義的類可以如下所示：

public class userDAOJDBC extends JdbcDaoSupport implements userDAO{ … }

　　如果使用Hibernate來實現(xiàn)這個DAO的時候，定義的類如下：

public class UserDAOHibernate extends HibernateDaoSupport implements UserDAO { … }

　　Spring對于其它的O/R映射機制都有相應的抽象類供應用使用，比如對于iBATIS有SqlMapClientDaoSupport，對于JDO有JdoDaoSupport等。

　　下面我們看一下如何在Spring的配置文件中定義上述DAO與具體實現(xiàn)的關系。假設我們的userDAO具體實現(xiàn)是通過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，而具體實現(xiàn)類為： com.fgw.dao.hibernate.UserDAOHibernate。顯然，對于其它DAO的實現(xiàn)，我們只需要在配置文件中修改相應的實現(xiàn)類 （具體實現(xiàn)類當然是比不可少的）和屬性即可。比如對于JDBC的DAO實現(xiàn)，屬性就定義成相應的數(shù)據(jù)源。

　　3、Spring與WebSphere應用服務器的配合

　　Spring與底層J2EE應用服務器還是存在一些需要結合的地方，這里給出WAS中的一些結合點。

　　3.1 使用WAS數(shù)據(jù)源

　 　在Java應用程序中，數(shù)據(jù)庫的連接一般有兩種方式來得到。一種是通過java.sql.DriverManager的方式來得到數(shù)據(jù)庫連接。這種方式 不依賴于應用服務的支持，但是也不提供數(shù)據(jù)庫連接池的功能。另外一種方式是通過javax.sql.DataSource的方式來得到數(shù)據(jù)庫連接。在傳統(tǒng) 基于J2EE的應用需要通過JNDI來得到數(shù)據(jù)源（javax.sql.DataSource）對象，然后再通過數(shù)據(jù)源來得到相應的數(shù)據(jù)庫連接。常見的應 用服務器都支持這種方式，且一般都提供了數(shù)據(jù)庫連接池的支持。雖然說我們一般推薦使用數(shù)據(jù)庫連接池，但是也有一些時候我們需要脫離開應用服務器的環(huán)境使用 數(shù)據(jù)庫（比如單元測試，比如應用移植等）。然而應用程序使用這兩種方式的時候代碼是不一樣的，因此只能通過代碼來應變。Spring提供了一個統(tǒng)一使用數(shù) 據(jù)源的解決方案，然后通過控制反轉的機制用外部配置文件來指定使用的數(shù)據(jù)源。這樣一方面可以統(tǒng)一這兩種得到數(shù)據(jù)庫連接的方式，另一方面也不需要像通常的 J2EE應用通過繁瑣的JNDI代碼來得到數(shù)據(jù)源。這樣應用程序也就不需要知道使用的何種數(shù)據(jù)源。

　　Spring提供了一個DriverManagerDataSource類來統(tǒng)一第一種方式的數(shù)據(jù)源獲取。如果使用WAS中的Cloudscape數(shù)據(jù)庫，用外部配置文件可配置如下：

＜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類來支持第二種方式的數(shù)據(jù)源獲取。假設WAS中已經(jīng)配置好的數(shù)據(jù)源名稱為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，應用程序能夠統(tǒng)一使用不同的數(shù)據(jù)源實現(xiàn)。如果使用環(huán)境發(fā)生變化，那么只需要修改Spring的配置文件 即可。對于部署在WAS上的Web應用，在生產(chǎn)環(huán)境中推薦使用WAS實現(xiàn)的數(shù)據(jù)庫連接池。一方面是因為連接池實現(xiàn)地比較完善。另一方面，使用WAS提供的 數(shù)據(jù)庫連接池可以很完善地支持JTA事務。

　　3.2 使用WAS的JTA

　　Web應用程序在使用事務的時候常常會涉 及一個事務類型的選擇。是選擇像JDBC事務這樣的本地事務呢還是使用JTA支持的全局事務。這個與應用程序需要涉及到的事務管理器類型和個數(shù)密切相關。 Spring本身不支持分布式事務，因此分布式事務需要底層的JTA。但是Spring提供了事務的抽象，即底層真正事務實現(xiàn)可以切換而不影響應用程序代 碼。這樣應用程序可以依賴于底層WAS，也可以輕易地脫離開應用服務器的環(huán)境。這一點與前面數(shù)據(jù)源的抽象非常類似。

　　WAS本身對于事 務劃分有兩種支持方式，一種是聲明式的，當然這種管理方式需要EJB容器的支持，即所謂的容器管理事務（CMT）。另外一種方式是編程式的，通過程序代碼 來直接使用JTA編程接口。Spring對于事務的劃分也可以分為聲明式和編程式兩種方式。對于Spring編程式的事務劃分方式，總體上可以分為兩大 類。一類是通過直接使用實現(xiàn)PlatformTransactionManager接口的類。另一類是通過使用TransactionTemplate模 板類，模板類的使用可以簡化事務控制代碼。Spring對于聲明式事務劃分的支持實際上是利用了它的AOP機制。相對于編程式事務劃分，這種基于AOP的 方式比較靈活，而且對代碼的侵入性幾乎為零。因此，如果沒有特殊需要推薦使用這種事務劃分方式。基于AOP的常用事務劃分方式可以使用 ProxyFactoryBean加TransactionInterceptor方式，或者使用 TransactionPorxyFactoryBean的方式。前一種方式相對比較靈活，而后一種則對使用相對比較簡單。

　　無論是哪 一種事務劃分方式，底層都需要一個事務管理機制作為支撐。如果是單一的事務資源管理器，那么根據(jù)所使用的后臺事務管理資源不同的類型，可以選擇的 PlatformTransactionManager實現(xiàn)有DataSourceTransactionManager， HibernateTransactionManager， JdoTransactionManager， PersistenceBrokerTransactionManager，和JmsTransactionManager等。無論是單個還是多個事務資 源管理器，都可以使用JtaTransactionManager類。如果使用JtaTransactionManager，那么所有事務管理實際都會委 托給底層應用服務器的JTA實現(xiàn)。

　　例如，如果使用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的事務支持，底層事務采用何種方式的決定就不必在一開始開發(fā)就做出決定。因為我們能夠通過Spring的外部配置文件來進行切換真 正的事務支持。不過，雖然也有第三方的JTA支持，但是WAS能夠提供非常穩(wěn)定的XA支持，因此推薦使用WAS的JTA，尤其是當應用涉及到分布事務處理 的時候。這樣無論應用涉及幾個事務資源都可以統(tǒng)一解決。

　　3.3 如何加載Spring的JAR包

　　Spring框 架的核心JAR包是spring.jar，但是根據(jù)實際使用情況需要一些擴展JAR包和依賴JAR包。那在WAS中如何處理這些JAR包文件呢？在Web 應用中一個簡單而直接的處理方式放是把這些使用到的JAR文件都拷貝到對應的WEB-INF/lib目錄下面。這種方法雖然簡單，但是當有多個 Spring應用程序的時候這種處理方式就需要在每個應用的WEB-INF/lib目錄下都拷貝一份相同的JAR文件。這里可以通過共享庫的方式來統(tǒng)一解 決類庫共享這個問題。

　　共享庫就是WAS專門用來解決不同應用程序之間共享JAR或本地庫文件的一種機制。共享庫由一個名字、一個 JAVA類路徑和/或一個裝載JNI庫本地庫路徑組成。它可以分別在單元，節(jié)點和服務器級別定義。但是共享庫定義了并不意味著它會被裝載，只有當這個共享 庫與某個應用程序或應用服務器關聯(lián)之后，它才會被加載。如果一個共享庫與一個應用程序關聯(lián)，那么這個共享庫由應用程序類加載器加載。如果一個共享庫與應用 服務器關聯(lián)，那么這個共享庫就需要一個專門定義的類加載器來加載。這個類加載器需要用戶自己定義。其操作如下：選應用服務器比如server1'類加載器 '新建一個類加載器'加載器與共享庫關聯(lián)。

　　在創(chuàng)建這個類加載器之前一般都需要預先定義好共享庫。 根據(jù)上面的介紹可知，通過共享庫解決Spring應用的JAR包共享問題，主要就是兩個步驟。一是，把Spring應用中需要共享的JAR包定義成為一個 共享庫。二是，選定相應的WAS服務器實例，把它與上面創(chuàng)建的共享庫關聯(lián)起來。這樣此WAS服務器實例上的所有應用都能夠使用共享庫中定義的JAR包。使 用共享庫這種方式的時候要注意理解類的裝載次序和方式。如果是這種與WAS服務器實例關聯(lián)的共享庫JAR包，其類加載器在層次結構上在應用程序類加載器上 面，即是它的父加載器。關于WAS的類裝載器結構和策略可以進一步參考WAS信息中心。

　　4、結束語

　 　Spring框架的核心內容并不依賴于任何容器，但是顯然基于Web的應用是Spring主要的應用類型。了解和使用Spring框架一方面可以簡化應 用的開發(fā)和測試，另一方也可以加深對J2EE技術的理解。另外輕量級的Web應用開發(fā)正在成為一種趨勢，因此何樂而不為之。上面所討論的只是Spring 使用中常見的一些內容，Spring框架自己也正變得越來越復雜。當然，Spring、Hibernate等框架中體現(xiàn)的一些思想也正被JEE 5規(guī)范所借鑒，尤其是EJB 3中也有了控制反轉的應用和POJO的大量使用。實際上無論是JEE技術標準還是Spring等框架，其目的都是如何簡化企業(yè)應用的開發(fā)，只是作為標準， JEE要考慮的內容更為廣泛一些，程度也更為深入一些。（源自：IBM ）