Apache Tomcat 是一款非常著(zhù)名的開(kāi)源 Servlet/JSP 容器。
Apache Tomcat 是一款非常著(zhù)名的開(kāi)源 Servlet/JSP 容器，被用做 Java Servlet 和 JavaServer Pages 技術(shù)的官方參考實(shí)現。如果您要了解這兩種技術(shù)的細節可以查閱
參考資料。
讓我們先來(lái)瀏覽一下 Tomcat 體系結構中的六個(gè)主要概念：
由于Tomcat體系結構的內容非常豐富，所以本文非常長(cháng)。因此我們盡量的使每一部分盡可能自成一體，使您可以獨立閱讀。如果您不是想全面了解Tomcat的體系結構，只是想解決某一部分的具體問(wèn)題，那么我們建議您使用目錄導航到相關(guān)的內容，而不必在其它的內容上花費寶貴的時(shí)間。
Server代表整個(gè)容器(container)。它可以包含一個(gè)或多個(gè)Service，還可以包含一個(gè)GlobalNamingResources。
值得注意的是在標準的Server接口中沒(méi)有包括Lifecycle接口，但是在標準實(shí)現org.apache.catalina.core.StandardServer中卻實(shí)現了Lifecycle這個(gè)接口，這使得我們可以為T(mén)omcat的標準實(shí)現設置Listener。一般的方法是在conf/server.xml文件中加入：
<Server port="8005" shutdown="SHUTDOWN">
<Listener className="org.solol.listener.XXXLifecycleListener" />
<Listener className="org.solol.listener.XXXLifecycleListener" />
:
:
:
</Server>
其中的XXXLifecycleListener為您自定義的LifecycleListener，而且必須要實(shí)現LifecycleListener接口。您可以在這里設置多個(gè)LifecycleListener，但要使用不同的名字。
由于在Tomcat的官方文檔中沒(méi)有顯著(zhù)的說(shuō)明，所以這種使用Listener的方式?jīng)]有體現在稍后給出的 體系結構圖 中。
Server支持className，port和shutdown三個(gè)公共屬性，而標準實(shí)現org.apache.catalina.core.StandardServer還可能支持一些擴展屬性。詳細的內容您可以查閱
這里。
您可以通過(guò)稍后給出的 體系結構圖 了解在整個(gè)Tomcat體系結構中Server所處的位置。
Service中可以含有一個(gè)或多個(gè)Connector，但只能含有一個(gè)Engine。這使得不同的Connector可以共享同一個(gè)Engine。同一個(gè)Server中的多個(gè)Service之間沒(méi)有相關(guān)性。
值得注意的是在標準的Service接口中沒(méi)有包括Lifecycle接口，但是在標準實(shí)現org.apache.catalina.core.StandardService中卻實(shí)現了Lifecycle這個(gè)接口，這使得我們可以為T(mén)omcat的標準實(shí)現設置Listener。
由于在Tomcat的官方文檔中沒(méi)有顯著(zhù)的說(shuō)明，所以這種使用Listener的方式?jīng)]有體現在稍后給出的 體系結構圖 中。
Service支持className和name兩個(gè)公共屬性，而標準實(shí)現org.apache.catalina.core.StandardService還可能支持一些擴展屬性。詳細的內容您可以查閱
這里。
您可以通過(guò)稍后給出的 體系結構圖 了解在整個(gè)Tomcat體系結構中Service所處的位置。
Engine負責接收和處理來(lái)自它所屬的Service中的所有Connector的請求。
Engine支持backgroundProcessorDelay、className、defaultHost、jvmRoute和name五個(gè)公共屬性，而標準實(shí)現org.apache.catalina.core.StandardEngine還可能支持一些擴展屬性。詳細的內容您可以查閱
這里。
您可以通過(guò)稍后給出的 體系結構圖 了解在整個(gè)Tomcat體系結構中Engine所處的位置。
從圖中可以看出Engine右邊有四個(gè)不同顏色的小方塊，它們表示Engine所支持的四個(gè)不同的特性。相同顏色的小方塊可能也會(huì )出現在其它的地方，這表示在那里也支持相同的或相似的特性。每種特性的具體描述可以在文中的Special Features中找到。
從圖中可以看出Engine下邊有一個(gè)紅色的圓角矩形，它們表示Engine所支持的一個(gè)內嵌組件。相同顏色的圓角矩形可能也會(huì )出現在其它的地方，這表示在那里也支持相同的或相似的內嵌組件。每種內嵌組件的具體描述可以在文中的Nested Components中找到。
Host表示一個(gè)虛擬主機，并和一個(gè)服務(wù)器的網(wǎng)絡(luò )名關(guān)聯(lián)。注意Engine中必須有一個(gè)Host的名字和Engine的defaultHost屬性匹配。
有時(shí)候，網(wǎng)絡(luò )管理員可能希望將多個(gè)網(wǎng)絡(luò )名關(guān)聯(lián)到一個(gè)虛擬主機，這可以通過(guò)下文介紹的Host Name Aliases特性完成。
Host支持appBase、autoDeploy、backgroundProcessorDelay、className、deployOnStartup和name六個(gè)公共屬性，而標準實(shí)現org.apache.catalina.core.StandardHost還可能支持一些擴展屬性。詳細的內容您可以查閱
這里。
您可以通過(guò)稍后給出的 體系結構圖 了解在整個(gè)Tomcat體系結構中Host所處的位置。
從圖中可以看出Host右邊有八個(gè)不同顏色的小方塊，它們表示Host所支持的八個(gè)不同的特性。相同顏色的小方塊可能也會(huì )出現在其它的地方，這表示在那里也支持相同的或相似的特性。每種特性的具體描述可以在文中的Special Features中找到。
從圖中可以看出Host下邊有一個(gè)紅色的圓角矩形，它們表示Host所支持的一個(gè)內嵌組件。相同顏色的圓角矩形可能也會(huì )出現在其它的地方，這表示在那里也支持相同的或相似的內嵌組件。每種內嵌組件的具體描述可以在文中的Nested Components中找到。
您可以通過(guò)稍后給出的 體系結構圖 了解在整個(gè)Tomcat體系結構中Connector所處的位置。
Context表示在虛擬主機中運行的web應用程序。一個(gè)虛擬主機中能夠運行多個(gè)Context，它們通過(guò)各自的Context Path進(jìn)行相互區分。如果Context Path為""，那么該web應用為該虛擬主機的默認的web應用。
目前可以通過(guò)四種方式將Context加入Host:
- $CATALINA_HOME/conf/context.xml，其中Context元素中的信息會(huì )被所有web應用程序加載
- $CATALINA_HOME/conf/[enginename]/[hostname]/context.xml.default，其中Context元素中的信息會(huì )被hostname主機下的所有web應用程序加載
- $CATALINA_HOME/conf/[enginename]/[hostname]/目錄中所有以.xml為擴展名的文件，其中Context元素中的信息會(huì )被hostname主機下的所有web應用程序加載
- 如果通過(guò)上面的步驟沒(méi)有找到，那么最后要從web應用程序的/META-INF/context.xml目錄中查找
Context支持backgroundProcessorDelay、className、cookies、crossContext、docBase、override、privileged、path、reloadable和wrapperClass十個(gè)公共屬性，而標準實(shí)現org.apache.catalina.core.StandardContext還可能支持一些擴展屬性。詳細的內容您可以查閱
這里。
您可以通過(guò)稍后給出的 體系結構圖 了解在整個(gè)Tomcat體系結構中Context所處的位置。
從圖中可以看出Context右邊有十個(gè)不同顏色的小方塊，它們表示Context所支持的十個(gè)不同的特性。相同顏色的小方塊可能也會(huì )出現在其它的地方，這表示在那里也支持相同的或相似的特性。每種特性的具體描述可以在文中的Special Features中找到。
從圖中可以看出Context下邊有五個(gè)不同顏色的圓角矩形，它們表示Context所支持的五個(gè)內嵌組件。相同顏色的圓角矩形可能也會(huì )出現在其它的地方，這表示在那里也支持相同的或相似的內嵌組件。每種內嵌組件的具體描述可以在文中的Nested Components中找到。
Tomcat 的體系結構圖
GlobalNamingResources 組件為 Server 定義全局 JNDI 資源。這些資源出現在 Server 的全局JNDI 資源上下文中。這個(gè)上下文和每個(gè) web 應用程序的 JNDI 上下文不同。在全局 JNDI 上下文中定義的資源在每個(gè) web應用程序的 JNDI 上下文中不可見(jiàn)，但是可以通過(guò) Resource Links 來(lái)改變這種可見(jiàn)性。如果您要了解在 Tomcat 中如何使用JNDI 資源可以查閱
參考資料。
從前面給出的 體系結構圖中可以看出GlobalNamingResources右邊有四個(gè)不同顏色的小方塊，它們表示GlobalNamingResources所支持的四個(gè)不同的特性。相同顏色的小方塊可能也會(huì )出現在其它的地方，這表示在那里也支持相同的或相似的特性。每種特性的具體描述可以在文中的SpecialFeatures中找到。
從前面給出的 體系結構圖 中可以看出，Realm組件在Engine、Host和Context中都有支持。
Realm是一個(gè)"數據庫"存儲著(zhù)用戶(hù)名、密碼和角色信息。通過(guò)自定義Realm可以將Catalina集成到其它的環(huán)境。Engine、Host和Context中的Realm可以被較低級別的容器繼承，即Host繼承Engine的Realm，Context繼承Host的Realm，除非我們顯示的禁止這種繼承。
Realm支持className一個(gè)公共屬性。Tomcat提供了多個(gè)實(shí)現：
- org.apache.catalina.realm.JDBCRealm
- org.apache.catalina.realm.DataSourceRealm
- org.apache.catalina.realm.JNDIRealm
- org.apache.catalina.realm.MemoryRealm
如果您要了解這些Realm的更多信息，可以查閱
這里。
如果您要了解這些Realm的更多的設置信息，可以查閱
參考資料。
從前面給出的 體系結構圖 中可以看出，Loader組件只在Context中都有支持。
Loader是web應用程序的類(lèi)裝載器。必須有一個(gè)類(lèi)裝載器按照Servlet Specification的要求從如下的位置裝載類(lèi)：
- 從web應用程序的/WEB-INF/classes目錄裝載
- 從web應用程序的/WEB-INF/lib目錄中的jar文件中裝載
- 從Catalina中裝載對于所有web應用可見(jiàn)的資源
Loader元素應該嵌入到Context元素中，如果沒(méi)有設置那么會(huì )自動(dòng)創(chuàng )建一個(gè)默認的Loader。如果想更深入的了解Catalina實(shí)現的Loader可以查閱
參考資料。
Loader支持className、delegate和reloadable三個(gè)公共屬性，而標準實(shí)現org.apache.catalina.loader.WebappLoader還可能支持一些擴展屬性。詳細的內容您可以查閱
這里。
從前面給出的 體系結構圖 中可以看出，Manager組件只在Context中有支持。
Manager是session管理器(session manager)，負責session的創(chuàng )建和維護。
Manager元素應該嵌入到Context元素中，如果沒(méi)有設置那么會(huì )自動(dòng)創(chuàng )建一個(gè)默認的Manager。
Manager 支持className和distributable兩個(gè)公共屬性，而標準實(shí)現org.apache.catalina.session.StandardManager和org.apache.catalina.session.PersistentManager還可能支持一些擴展屬性。詳細的內容您可以查閱
這里。
從前面給出的 體系結構圖 中可以看出，Resources組件只在Context中有支持。
Resources表示web應用程序的靜態(tài)資源。這使得我們有可能實(shí)現non-filesystem based Resources。如果想更深入的了解可以查閱
參考資料Resources元素應該嵌入到Context元素中，如果沒(méi)有設置那么會(huì )自動(dòng)創(chuàng )建一個(gè)默認的基于文件系統的Resources。
Resources支持className一個(gè)公共屬性，而標準實(shí)現org.apache.naming.resources.FileDirContext還可能支持一些擴展屬性。詳細的內容您可以查閱
這里。
從前面給出的 體系結構圖 中可以看出，WatchedResource組件只在Context中都有支持。
WatchedResource用來(lái)告知Auto Deployer那些靜態(tài)資源的更新需要被監控。如果被監控的資源被更新了那么該資源所對應的web應用將會(huì )被重新裝載。這個(gè)元素的內容必須是一個(gè)String。
從前面給出的 體系結構圖 中可以看出，Logging特性在Engine、Host和Context中都有支持。這個(gè)特性使得我們可以區分日志記錄的具體來(lái)源。
在Engine、Host和Context中的日志類(lèi)別分別為：
org.apache.catalina.core.ContainerBase.[enginename] org.apache.catalina.core.ContainerBase.[enginename].[hostname] org.apache.catalina.core.ContainerBase.[enginename].[hostname].[path]
其中中括號([])中為具體的名稱(chēng)。
Logging特性的實(shí)現是通過(guò)org.apache.catalina.core.ContainerBase來(lái)完成的。
從前面給出的 體系結構圖 中可以看出，Access Logs特性在Engine、Host和Context中都有支持。
- Engine中的Access Logs記錄所有Engine處理的請求的訪(fǎng)問(wèn)日志
- Host中的Access Logs記錄所有Host處理的請求的訪(fǎng)問(wèn)日志
- Context中的Access Logs記錄所有Context處理的請求的訪(fǎng)問(wèn)日志
一般的配置方法是在conf/server.xml文件的相關(guān)元素中加入：
<Engine ...>
...
<Valve className="org.apache.catalina.valves.AccessLogValve"
prefix="catalina_access_log." suffix=".txt" pattern="common"/>
...
</Engine>
上面的<Engine>，在Host中要被換成<Host>，在Context中要被換成<Context>。
Access Logs特性的實(shí)現是通過(guò)Tomcat的Value框架來(lái)完成的。如果您要了解這種技術(shù)的細節可以查閱
參考資料。
如果您要了解Access Log Valve設置的更多信息，可以查閱
這里。
從前面給出的 體系結構圖 中可以看出，Lifecycle Listeners特性在Engine、Host和Context中都有支持。這個(gè)特性使得我們可以方便的進(jìn)行生命周期的管理。
值得一提的是在Tomcat的標準實(shí)現中Server和Service也支持生命周期的管理，但是在官方文檔中沒(méi)有顯著(zhù)的說(shuō)明，所以沒(méi)有在圖中體現出來(lái)。細節可以查閱Server和Service部分。
- Engine中的Lifecycle Listeners監聽(tīng)該Engine的生命周期事件(Eifecycle Event)
- Host中的Lifecycle Listeners監聽(tīng)該Host的生命周期事件(Eifecycle Event)
- Context中的Lifecycle Listeners監聽(tīng)該Context的生命周期事件(Eifecycle Event)
一般的配置方法是在conf/server.xml文件的相關(guān)元素中加入：
<Engine ...>
...
<Listener className="com.mycompany.mypackage.MyListener" ... >
...
</Engine>
上面的<Engine>，在Host中要被換成<Host>，在Context中要被換成<Context>。
另外，可以通過(guò)<Listener>元素為listener添加屬性。
注意和Container Event區別。
從前面給出的 體系結構圖 中可以看出，Request Filters特性在Engine、Host和Context中都有支持。
- Engine中的Request Filters過(guò)濾所有Engine處理的請求
- Host中的Request Filters過(guò)濾所有Host處理的請求
- Context中的Request Filters過(guò)濾所有Context處理的請求
一般的配置方法是在conf/server.xml文件的相關(guān)元素中加入：
<Engine ...>
...
<Valve className="org.apache.catalina.valves.RemoteHostValve"
allow="*.mycompany.com,www.yourcompany.com"/>
<Valve className="org.apache.catalina.valves.RemoteAddrValve"
deny="192.168.1.*"/>
...
</Engine/>
上面的<Engine>，在Host中要被換成<Host>，在Context中要被換成<Context>。
Request Filters特性的實(shí)現是通過(guò)Tomcat的Value框架來(lái)完成的。如果您要了解這種技術(shù)的細節可以查閱
參考資料。
如果您要了解Remote Address Filter設置的更多信息，可以查閱
這里。
如果您要了解Remote Host Filter設置的更多信息，可以查閱
這里。
從前面給出的 體系結構圖 中可以看出，Automatic Application Deployment特性只在Host中都有支持。
如果使用Host的標準實(shí)現，同時(shí)deployOnStartup屬性值為true(這是默認值)，那么Catalina在首次啟動(dòng)時(shí)會(huì )自動(dòng)完成下面的工作：
- $CATALINA_HOME/conf/[engine_name]/[host_name]目錄下的所有XML文件都被假定含有<Context>元素。
- appBase 目錄下的所有沒(méi)有展開(kāi)的war文件(沒(méi)有展開(kāi)的意思是沒(méi)有和war文件名不包括.war擴展名對應的目錄存在)會(huì )被自動(dòng)展開(kāi)，除非unpackWARs屬 性值為false。如果重新部署更新的war文件，在重起Tomcat之前要刪除先前展開(kāi)的目錄(如果autoDeploy屬性值為true那么只要刪除 先前展開(kāi)的目錄更新后的war文件就會(huì )自動(dòng)展開(kāi))。
- 對 于appBase中含有/WEB-INF/web.xml文件的任何子目錄都會(huì )自動(dòng)產(chǎn)生一個(gè)Context，不管該子目錄是否在conf /server.xml文件中出現過(guò)。這個(gè)新產(chǎn)生的Context將會(huì )根據DefaultContext的屬性值進(jìn)行設置，其context path為“/目錄名”。如果目錄名為ROOT，那么context path為“”。
因此要使用上面的規則需要將XML設置文件拷貝到$CATALINA_HOME/conf/[engine_name]/[host_name]目錄下或將war文件和含有web應用的目錄拷貝到appBase目錄下。
自動(dòng)部署(Auto Deployer)也會(huì )跟蹤如下web應用程序的變化：
- 更新WEB-INF/web.xml文件將會(huì )使web應用程序重新加載
- 更新已展開(kāi)的war文件會(huì )使web應用程序卸載(undeploy)(同時(shí)移除先前展開(kāi)的目錄)并重新部署(deployment)
- 更新XML設置文件會(huì )使web應用程序卸載(undeploy)(不移除任何展開(kāi)的目錄)并重新部署(deployment)
在使用自動(dòng)部署的時(shí)候XML設置文件中的docBase要指向appBase目錄之外。否則部署將很困難或應用程序會(huì )被部署兩次。
如果要顯示的定義context，那么需要關(guān)閉自動(dòng)部署。否則相應的context將會(huì )部署兩次，這可能會(huì )有問(wèn)題。
從前面給出的 體系結構圖 中可以看出，Host Name Aliases特性只在Host中都有支持。
在一些時(shí)候，網(wǎng)絡(luò )管理員會(huì )將多個(gè)網(wǎng)絡(luò )名(在DNS服務(wù)器中)解析到同一個(gè)服務(wù)器。通常每一個(gè)網(wǎng)絡(luò )名會(huì )對應到一個(gè)Host。不過(guò)有時(shí)候需要將多個(gè)網(wǎng)絡(luò )名對應到一個(gè)Host，Host Name Aliases用來(lái)完成這個(gè)目標。
一般的配置方法是在conf/server.xml文件的相關(guān)元素中加入：
<Host name="www.mycompany.com" ...>
...
<Alias>mycompany.com</Alias>
...
</Host>
<Host>元素中可以嵌入一個(gè)或多個(gè)<Alias>元素。
從前面給出的 體系結構圖 中可以看出，Single Sign On特性只在Host中都有支持。
在一些時(shí)候，特別是在Portal環(huán)境下，可能會(huì )希望當用戶(hù)訪(fǎng)問(wèn)一個(gè)虛擬主機下的多個(gè)web應用時(shí)只登陸一次，即所謂的單點(diǎn)登陸。
一般的配置方法是在conf/server.xml文件的相關(guān)元素中加入：
<Host name="localhost" ...>
...
<Valve className="org.apache.catalina.authenticator.SingleSignOn"
debug="0"/>
...
</Host>
Single Sign On操作遵循下面的規則：
- 該虛擬主機下的所有Web應用程序必須共享同一個(gè)Realm。在實(shí)踐中通常通過(guò)為Host或(對應的Engine)嵌入Realm而不是為每一個(gè)Context嵌入相同的Realm來(lái)實(shí)現。
- 在用戶(hù)訪(fǎng)問(wèn)該虛擬主機下的所有Web應用程序中的非保護資源時(shí)不需要驗證。
- 在用戶(hù)訪(fǎng)問(wèn)該虛擬主機下的所有Web應用程序中的保護資源時(shí)需要驗證。
- 一旦被驗證，就會(huì )對該虛擬主機下的所有Web應用程序有效，而不用每個(gè)應用程序單獨驗證。
- 如果用戶(hù)從一個(gè)Web應用中退出，那么所有Web應用程序中的session都會(huì )失效。
- 使用SSO需要客戶(hù)環(huán)境支持cookies。
Single Sign On特性的實(shí)現是通過(guò)Tomcat的Value框架來(lái)完成的。如果您要了解這種技術(shù)的細節可以查閱
參考資料。
如果您要了解Single Sign On設置的更多信息，可以查閱
這里。
從前面給出的 體系結構圖 中可以看出，User Web Applications特性只在Host中都有支持。
許多Web服務(wù)器都可以處理如下形式的請求：
http://www.mycompany.com:8080/~craigmcc
其中craigmcc為系統的一位用戶(hù)名。具體的處理過(guò)程和操作系統相關(guān)。
在類(lèi)Unix或Linux等操作系統下配置方法如下：
<Host name="localhost" ...>
...
<Listener className="org.apache.catalina.startup.UserConfig"
directoryName="public_html"
userClass="org.apache.catalina.startup.PasswdUserDatabase"/>
...
</Host>
在Windows等操作系統下配置方法如下：
<Host name="localhost" ...>
...
<Listener className="org.apache.catalina.startup.UserConfig"
directoryName="public_html"
homeBase="c:\Homes"
userClass="org.apache.catalina.startup.HomesUserDatabase"/>
...
</Host>
這兩種配置最主要的區別就是發(fā)現用戶(hù)和為用戶(hù)匹配路徑。PasswdUserDatabase依據/etc/passwd發(fā)現用戶(hù)而HomesUserDatabase依據homeBase="c:\Homes"發(fā)現用戶(hù)。
User Web Applications是通過(guò)Listener(org.apache.catalina.startup.UserConfig)的方式實(shí)現的。即在Host啟動(dòng)時(shí)該Listener會(huì )被執行，它會(huì )為每一個(gè)發(fā)現的用戶(hù)構建對應Context。
使用User Web Applications時(shí)需要考慮以下的一些問(wèn)題：
- 依據DefaultContext來(lái)設置為每一個(gè)用戶(hù)建立Context
- 可以使用多個(gè)Listener元素(在這么做之前您最好查閱一下UserConfig)
- 用戶(hù)所對應的目錄應該具有讀寫(xiě)權限
從前面給出的 體系結構圖 中可以看出，Automatic Context Configuration特性只在Context中都有支持。
如果使用標準的Context實(shí)現，當Catalina啟動(dòng)或Web應用裝載時(shí)，會(huì )按如下的步驟自動(dòng)進(jìn)行設置：
- 如果沒(méi)有指定Loader元素，那么一個(gè)標準的Loader將會(huì )被設置
- 如果沒(méi)有指定Manager元素，那么一個(gè)標準的Manager將會(huì )被設置
- 如果沒(méi)有指定Resources元素，那么一個(gè)標準的Resources將會(huì )被設置
- 處理conf/web.xml文件
- 處理/WEB-INF/web.xml文件
- 如果設置了security constraints，那么一個(gè)對應的Authenticator會(huì )被創(chuàng )建
從前面給出的 體系結構圖 中可以看出，Context Parameters特性只在Context中有支持。
如下的兩種配置等價(jià)，都是為Web配置初始參數:
<Context ...>
...
<Parameter name="companyName" value="My Company, Incorporated" override="false"/>
...
</Context>
<context-param>
<param-name>companyName</param-name>
<param-value>My Company, Incorporated</param-value>
</context-param>
從前面給出的 體系結構圖 中可以看出，Environment Entries特性在GlobalNamingResources和Context中都有支持。
如下的兩種配置等價(jià)，都是為配置environment entry resources：
<GlobalNamingResources ...>
...
<Environment name="maxExemptions" value="10" type="java.lang.Integer" override="false"/>
...
</GlobalNamingResources>
<env-entry>
<env-entry-name>maxExemptions</param-name>
<env-entry-value>10</env-entry-value>
<env-entry-type>java.lang.Integer</env-entry-type>
</env-entry>
這里使用GlobalNamingResources表示environment entry resources對于所有Web應用程序可見(jiàn)。如果換成Context則表示只對相應Web應用程序可見(jiàn)。
從前面給出的 體系結構圖 中可以看出，Resource Definitions特性在GlobalNamingResources和Context中都有支持。
如下的兩種配置等價(jià)，都是為定義Resource：
<GlobalNamingResources ...>
...
<Resource name="jdbc/EmployeeDB" auth="Container" type="javax.sql.DataSource"
description="Employees Database for HR Applications"/>
...
</GlobalNamingResources>
<resource-ref>
<description>Employees Database for HR Applications</description>
<res-ref-name>jdbc/EmployeeDB</res-ref-name>
<res-ref-type>javax.sql.DataSource</res-ref-type>
<res-auth>Container</res-auth>
</resource-ref>
這里使用GlobalNamingResources表示Resource對于所有Web應用程序可見(jiàn)。如果換成Context則表示只對相應Web應用程序可見(jiàn)。
從前面給出的 體系結構圖 中可以看出，Resource Links特性在GlobalNamingResources和Context中都有支持。
ResourceLink 元素用來(lái)將資源從全局上下文(globalcontext)中連接到每個(gè)Web應用的上下文(per-web-applicationcontexts)中。使用方式依據GlobalNamingResources和Context的不同分成兩種：
<DefaultContext>
<ResourceLink name="bean/MyBeanFactory" global="bean/MyBeanFactory" type="com.mycompany.MyBean"/>
</DefaultContext>
<Context ...>
...
<ResourceLink name="linkToGlobalResource" global="simpleValue" type="java.lang.Integer"/>
...
</Context>
從前面給出的 體系結構圖 中可以看出，Transaction特性在GlobalNamingResources和Context中都有支持。
通過(guò)在JNDI中查詢(xún)java:comp/UserTransaction可以得到UserTransaction的引用。
