亚洲综合无码无在线观看,亚洲精品在线播放,亚洲Av高清一区二区三区

圖解 Tomcat 體系結構

Apache Tomcat 是一款非常著名的開源 Servlet/JSP 容器。

原文：http://www.solol.org/technologic/java/j-tomcatarch/

Apache Tomcat 是一款非常著名的開源 Servlet/JSP 容器，被用做 Java Servlet 和 JavaServer Pages 技術的官方參考實現。如果您要了解這兩種技術的細節可以查閱參考資料。

讓我們先來瀏覽一下 Tomcat 體系結構中的六個主要概念：

Server
Service
Engine
Host
Connector
Context

由于Tomcat體系結構的內容非常豐富，所以本文非常長。因此我們盡量的使每一部分盡可能自成一體，使您可以獨立閱讀。如果您不是想全面了解Tomcat 的體系結構，只是想解決某一部分的具體問題，那么我們建議您使用目錄導航到相關的內容，而不必在其它的內容上花費寶貴的時間。

Server

Server代表整個容器(container)。它可以包含一個或多個Service，還可以包含一個GlobalNamingResources。

值得注意的是在標準的Server接口中沒有包括Lifecycle接口，但是在標準實現 org.apache.catalina.core.StandardServer中卻實現了Lifecycle這個接口，這使得我們可以為Tomcat 的標準實現設置Listener。一般的方法是在conf/server.xml文件中加入：

<Server port="8005" shutdown="SHUTDOWN">



<Listener className="org.solol.listener.XXXLifecycleListener" />

<Listener className="org.solol.listener.XXXLifecycleListener" />

:

:

:



</Server>

其中的XXXLifecycleListener為您自定義的LifecycleListener，而且必須要實現LifecycleListener接口。您可以在這里設置多個LifecycleListener，但要使用不同的名字。

由于在Tomcat的官方文檔中沒有顯著的說明，所以這種使用Listener的方式沒有體現在稍后給出的 體系結構圖 中。

Server支持className，port和shutdown三個公共屬性，而標準實現org.apache.catalina.core.StandardServer還可能支持一些擴展屬性。詳細的內容您可以查閱這里。

您可以通過稍后給出的 體系結構圖 了解在整個Tomcat體系結構中Server所處的位置。

回頁首

Service

Service中可以含有一個或多個Connector，但只能含有一個Engine。這使得不同的Connector可以共享同一個Engine。同一個Server中的多個Service之間沒有相關性。

值得注意的是在標準的Service接口中沒有包括Lifecycle接口，但是在標準實現 org.apache.catalina.core.StandardService中卻實現了Lifecycle這個接口，這使得我們可以為 Tomcat的標準實現設置Listener。

由于在Tomcat的官方文檔中沒有顯著的說明，所以這種使用Listener的方式沒有體現在稍后給出的 體系結構圖 中。

Service支持className和name兩個公共屬性，而標準實現org.apache.catalina.core.StandardService還可能支持一些擴展屬性。詳細的內容您可以查閱這里。

您可以通過稍后給出的 體系結構圖 了解在整個Tomcat體系結構中Service所處的位置。

回頁首

Engine

Engine負責接收和處理來自它所屬的Service中的所有Connector的請求。

Engine 支持backgroundProcessorDelay、className、defaultHost、jvmRoute和name五個公共屬性，而標準實現org.apache.catalina.core.StandardEngine還可能支持一些擴展屬性。詳細的內容您可以查閱這里。

您可以通過稍后給出的 體系結構圖 了解在整個Tomcat體系結構中Engine所處的位置。

從圖中可以看出Engine右邊有四個不同顏色的小方塊，它們表示Engine所支持的四個不同的特性。相同顏色的小方塊可能也會出現在其它的地方，這表示在那里也支持相同的或相似的特性。每種特性的具體描述可以在文中的Special Features中找到。

從圖中可以看出Engine下邊有一個紅色的圓角矩形，它們表示Engine所支持的一個內嵌組件。相同顏色的圓角矩形可能也會出現在其它的地方，這表示在那里也支持相同的或相似的內嵌組件。每種內嵌組件的具體描述可以在文中的Nested Components中找到。

回頁首

Host

Host表示一個虛擬主機，并和一個服務器的網絡名關聯。注意Engine中必須有一個Host的名字和Engine的defaultHost屬性匹配。

有時候，網絡管理員可能希望將多個網絡名關聯到一個虛擬主機，這可以通過下文介紹的Host Name Aliases特性完成。

Host 支持appBase、autoDeploy、backgroundProcessorDelay、className、deployOnStartup和 name六個公共屬性，而標準實現org.apache.catalina.core.StandardHost還可能支持一些擴展屬性。詳細的內容您可以查閱這里。

您可以通過稍后給出的 體系結構圖 了解在整個Tomcat體系結構中Host所處的位置。

從圖中可以看出Host右邊有八個不同顏色的小方塊，它們表示Host所支持的八個不同的特性。相同顏色的小方塊可能也會出現在其它的地方，這表示在那里也支持相同的或相似的特性。每種特性的具體描述可以在文中的Special Features中找到。

從圖中可以看出Host下邊有一個紅色的圓角矩形，它們表示Host所支持的一個內嵌組件。相同顏色的圓角矩形可能也會出現在其它的地方，這表示在那里也支持相同的或相似的內嵌組件。每種內嵌組件的具體描述可以在文中的Nested Components中找到。

回頁首

Connector

Connector負責接收來自客戶端(Client)的請求。比較常見的兩個是HTTP Connector和AJP Connector。

您可以通過稍后給出的 體系結構圖 了解在整個Tomcat體系結構中Connector所處的位置。

回頁首

Context

Context表示在虛擬主機中運行的web應用程序。一個虛擬主機中能夠運行多個Context，它們通過各自的Context Path進行相互區分。如果Context Path為""，那么該web應用為該虛擬主機的默認的web應用。

目前可以通過四種方式將Context加入Host:

$CATALINA_HOME/conf/context.xml，其中Context元素中的信息會被所有web應用程序加載
$CATALINA_HOME/conf/[enginename]/[hostname]/context.xml.default，其中Context元素中的信息會被hostname主機下的所有web應用程序加載
$CATALINA_HOME/conf/[enginename]/[hostname]/目錄中所有以.xml為擴展名的文件，其中Context元素中的信息會被hostname主機下的所有web應用程序加載
如果通過上面的步驟沒有找到，那么最后要從web應用程序的/META-INF/context.xml目錄中查找

Context 支持backgroundProcessorDelay、className、cookies、crossContext、docBase、 override、privileged、path、reloadable和wrapperClass十個公共屬性，而標準實現 org.apache.catalina.core.StandardContext還可能支持一些擴展屬性。詳細的內容您可以查閱這里。

您可以通過稍后給出的 體系結構圖 了解在整個Tomcat體系結構中Context所處的位置。

從圖中可以看出Context右邊有十個不同顏色的小方塊，它們表示Context所支持的十個不同的特性。相同顏色的小方塊可能也會出現在其它的地方，這表示在那里也支持相同的或相似的特性。每種特性的具體描述可以在文中的Special Features中找到。

從圖中可以看出Context下邊有五個不同顏色的圓角矩形，它們表示Context所支持的五個內嵌組件。相同顏色的圓角矩形可能也會出現在其它的地方，這表示在那里也支持相同的或相似的內嵌組件。每種內嵌組件的具體描述可以在文中的Nested Components中找到。

體系結構圖

Tomcat 的體系結構圖

Nested Components

GlobalNamingResources

GlobalNamingResources 組件為 Server 定義全局 JNDI 資源。這些資源出現在 Server 的全局 JNDI 資源上下文中。這個上下文和每個 web 應用程序的 JNDI 上下文不同。在全局 JNDI 上下文中定義的資源在每個 web 應用程序的 JNDI 上下文中不可見，但是可以通過 Resource Links 來改變這種可見性。如果您要了解在 Tomcat 中如何使用 JNDI 資源可以查閱參考資料。

從前面給出的 體系結構圖 中可以看出GlobalNamingResources右邊有四個不同顏色的小方塊，它們表示GlobalNamingResources所支持的四個不同的特性。相同顏色的小方塊可能也會出現在其它的地方，這表示在那里也支持相同的或相似的特性。每種特性的具體描述可以在文中的Special Features中找到。

Realm

從前面給出的 體系結構圖 中可以看出，Realm組件在Engine、Host和Context中都有支持。

Realm 是一個"數據庫"存儲著用戶名、密碼和角色信息。通過自定義Realm可以將Catalina集成到其它的環境。Engine、Host和Context 中的Realm可以被較低級別的容器繼承，即Host繼承Engine的Realm，Context繼承Host的Realm，除非我們顯示的禁止這種繼承。

Realm支持className一個公共屬性。Tomcat提供了多個實現：

org.apache.catalina.realm.JDBCRealm
org.apache.catalina.realm.DataSourceRealm
org.apache.catalina.realm.JNDIRealm
org.apache.catalina.realm.MemoryRealm

如果您要了解這些Realm的更多信息，可以查閱這里。

如果您要了解這些Realm的更多的設置信息，可以查閱參考資料。

Loader

從前面給出的 體系結構圖 中可以看出，Loader組件只在Context中都有支持。

Loader是web應用程序的類裝載器。必須有一個類裝載器按照Servlet Specification的要求從如下的位置裝載類：

從web應用程序的/WEB-INF/classes目錄裝載
從web應用程序的/WEB-INF/lib目錄中的jar文件中裝載
從Catalina中裝載對于所有web應用可見的資源

Loader元素應該嵌入到Context元素中，如果沒有設置那么會自動創建一個默認的Loader。如果想更深入的了解Catalina實現的Loader可以查閱參考資料。

Loader支持className、delegate和reloadable三個公共屬性，而標準實現org.apache.catalina.loader.WebappLoader還可能支持一些擴展屬性。詳細的內容您可以查閱這里。

Manager

從前面給出的 體系結構圖 中可以看出，Manager組件只在Context中有支持。

Manager是session管理器(session manager)，負責session的創建和維護。

Manager元素應該嵌入到Context元素中，如果沒有設置那么會自動創建一個默認的Manager。

Manager 支持className和distributable兩個公共屬性，而標準實現 org.apache.catalina.session.StandardManager和 org.apache.catalina.session.PersistentManager還可能支持一些擴展屬性。詳細的內容您可以查閱這里。

Resources

從前面給出的 體系結構圖 中可以看出，Resources組件只在Context中有支持。

Resources表示web應用程序的靜態資源。這使得我們有可能實現non-filesystem based Resources。如果想更深入的了解可以查閱參考資料

Resources元素應該嵌入到Context元素中，如果沒有設置那么會自動創建一個默認的基于文件系統的Resources。

Resources支持className一個公共屬性，而標準實現org.apache.naming.resources.FileDirContext還可能支持一些擴展屬性。詳細的內容您可以查閱這里。

WatchedResource

從前面給出的 體系結構圖 中可以看出，WatchedResource組件只在Context中都有支持。

WatchedResource用來告知Auto Deployer那些靜態資源的更新需要被監控。如果被監控的資源被更新了那么該資源所對應的web應用將會被重新裝載。這個元素的內容必須是一個String。

回頁首

Special Features

Logging

從前面給出的 體系結構圖 中可以看出，Logging特性在Engine、Host和Context中都有支持。這個特性使得我們可以區分日志記錄的具體來源。

在Engine、Host和Context中的日志類別分別為：

org.apache.catalina.core.ContainerBase.[enginename]
org.apache.catalina.core.ContainerBase.[enginename].[hostname]
org.apache.catalina.core.ContainerBase.[enginename].[hostname].[path]

其中中括號([])中為具體的名稱。

Logging特性的實現是通過org.apache.catalina.core.ContainerBase來完成的。

Access Logs

從前面給出的 體系結構圖 中可以看出，Access Logs特性在Engine、Host和Context中都有支持。

Engine中的Access Logs記錄所有Engine處理的請求的訪問日志
Host中的Access Logs記錄所有Host處理的請求的訪問日志
Context中的Access Logs記錄所有Context處理的請求的訪問日志

一般的配置方法是在conf/server.xml文件的相關元素中加入：

<Engine ...>

...

<Valve className="org.apache.catalina.valves.AccessLogValve"

prefix="catalina_access_log." suffix=".txt" pattern="common"/>

...

</Engine>

上面的<Engine>，在Host中要被換成<Host>，在Context中要被換成<Context>。

Access Logs特性的實現是通過Tomcat的Value框架來完成的。如果您要了解這種技術的細節可以查閱參考資料。

如果您要了解Access Log Valve設置的更多信息，可以查閱這里。

Lifecycle Listeners

從前面給出的 體系結構圖 中可以看出，Lifecycle Listeners特性在Engine、Host和Context中都有支持。這個特性使得我們可以方便的進行生命周期的管理。

值得一提的是在Tomcat的標準實現中Server和Service也支持生命周期的管理，但是在官方文檔中沒有顯著的說明，所以沒有在圖中體現出來。細節可以查閱Server和Service部分。

Engine中的Lifecycle Listeners監聽該Engine的生命周期事件(Eifecycle Event)
Host中的Lifecycle Listeners監聽該Host的生命周期事件(Eifecycle Event)
Context中的Lifecycle Listeners監聽該Context的生命周期事件(Eifecycle Event)

一般的配置方法是在conf/server.xml文件的相關元素中加入：

<Engine ...>

...

<Listener className="com.mycompany.mypackage.MyListener" ... >

...

</Engine>

上面的<Engine>，在Host中要被換成<Host>，在Context中要被換成<Context>。

另外，可以通過<Listener>元素為listener添加屬性。

注意和Container Event區別。

Request Filters

從前面給出的 體系結構圖 中可以看出，Request Filters特性在Engine、Host和Context中都有支持。

Engine中的Request Filters過濾所有Engine處理的請求
Host中的Request Filters過濾所有Host處理的請求
Context中的Request Filters過濾所有Context處理的請求

一般的配置方法是在conf/server.xml文件的相關元素中加入：

<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特性的實現是通過Tomcat的Value框架來完成的。如果您要了解這種技術的細節可以查閱參考資料。

如果您要了解Remote Address Filter設置的更多信息，可以查閱這里。

如果您要了解Remote Host Filter設置的更多信息，可以查閱這里。

Automatic Application Deployment

從前面給出的 體系結構圖 中可以看出，Automatic Application Deployment特性只在Host中都有支持。

如果使用Host的標準實現，同時deployOnStartup屬性值為true(這是默認值)，那么Catalina在首次啟動時會自動完成下面的工作：

$CATALINA_HOME/conf/[engine_name]/[host_name]目錄下的所有XML文件都被假定含有<Context>元素。
appBase 目錄下的所有沒有展開的war文件(沒有展開的意思是沒有和war文件名不包括.war擴展名對應的目錄存在)會被自動展開，除非unpackWARs屬性值為false。如果重新部署更新的war文件，在重起Tomcat之前要刪除先前展開的目錄(如果autoDeploy屬性值為true那么只要刪除先前展開的目錄更新后的war文件就會自動展開)。
對于appBase中含有/WEB-INF/web.xml文件的任何子目錄都會自動產生一個Context，不管該子目錄是否在conf /server.xml文件中出現過。這個新產生的Context將會根據DefaultContext的屬性值進行設置，其context path為“/目錄名”。如果目錄名為ROOT，那么context path為“”。

因此要使用上面的規則需要將XML設置文件拷貝到$CATALINA_HOME/conf/[engine_name]/[host_name]目錄下或將war文件和含有web應用的目錄拷貝到appBase目錄下。

自動部署(Auto Deployer)也會跟蹤如下web應用程序的變化：

更新WEB-INF/web.xml文件將會使web應用程序重新加載
更新已展開的war文件會使web應用程序卸載(undeploy)(同時移除先前展開的目錄)并重新部署(deployment)
更新XML設置文件會使web應用程序卸載(undeploy)(不移除任何展開的目錄)并重新部署(deployment)

在使用自動部署的時候XML設置文件中的docBase要指向appBase目錄之外。否則部署將很困難或應用程序會被部署兩次。

如果要顯示的定義context，那么需要關閉自動部署。否則相應的context將會部署兩次，這可能會有問題。

Host Name Aliases

從前面給出的 體系結構圖 中可以看出，Host Name Aliases特性只在Host中都有支持。

在一些時候，網絡管理員會將多個網絡名(在DNS服務器中)解析到同一個服務器。通常每一個網絡名會對應到一個Host。不過有時候需要將多個網絡名對應到一個Host，Host Name Aliases用來完成這個目標。

一般的配置方法是在conf/server.xml文件的相關元素中加入：

<Host name="www.mycompany.com" ...>

...

<Alias>mycompany.com</Alias>

...

</Host>

<Host>元素中可以嵌入一個或多個<Alias>元素。

Single Sign On

從前面給出的 體系結構圖 中可以看出，Single Sign On特性只在Host中都有支持。

在一些時候，特別是在Portal環境下，可能會希望當用戶訪問一個虛擬主機下的多個web應用時只登陸一次，即所謂的單點登陸。

一般的配置方法是在conf/server.xml文件的相關元素中加入：

<Host name="localhost" ...>

...

<Valve className="org.apache.catalina.authenticator.SingleSignOn"

debug="0"/>

...

</Host>

Single Sign On操作遵循下面的規則：

該虛擬主機下的所有Web應用程序必須共享同一個Realm。在實踐中通常通過為Host或(對應的Engine)嵌入Realm而不是為每一個Context嵌入相同的Realm來實現。
在用戶訪問該虛擬主機下的所有Web應用程序中的非保護資源時不需要驗證。
在用戶訪問該虛擬主機下的所有Web應用程序中的保護資源時需要驗證。
一旦被驗證，就會對該虛擬主機下的所有Web應用程序有效，而不用每個應用程序單獨驗證。
如果用戶從一個Web應用中退出，那么所有Web應用程序中的session都會失效。
使用SSO需要客戶環境支持cookies。

Single Sign On特性的實現是通過Tomcat的Value框架來完成的。如果您要了解這種技術的細節可以查閱參考資料。

如果您要了解Single Sign On設置的更多信息，可以查閱這里。

User Web Applications

從前面給出的 體系結構圖 中可以看出，User Web Applications特性只在Host中都有支持。

許多Web服務器都可以處理如下形式的請求：

  http://www.mycompany.com:8080/~craigmcc

其中craigmcc為系統的一位用戶名。具體的處理過程和操作系統相關。

在類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>

這兩種配置最主要的區別就是發現用戶和為用戶匹配路徑。PasswdUserDatabase依據/etc/passwd發現用戶而HomesUserDatabase依據homeBase="c:\Homes"發現用戶。

User Web Applications是通過Listener(org.apache.catalina.startup.UserConfig)的方式實現的。即在Host啟動時該Listener會被執行，它會為每一個發現的用戶構建對應Context。

使用User Web Applications時需要考慮以下的一些問題：

依據DefaultContext來設置為每一個用戶建立Context
可以使用多個Listener元素(在這么做之前您最好查閱一下UserConfig)
用戶所對應的目錄應該具有讀寫權限

Automatic Context Configuration

從前面給出的 體系結構圖 中可以看出，Automatic Context Configuration特性只在Context中都有支持。

如果使用標準的Context實現，當Catalina啟動或Web應用裝載時，會按如下的步驟自動進行設置：

如果沒有指定Loader元素，那么一個標準的Loader將會被設置
如果沒有指定Manager元素，那么一個標準的Manager將會被設置
如果沒有指定Resources元素，那么一個標準的Resources將會被設置
處理conf/web.xml文件
處理/WEB-INF/web.xml文件
如果設置了security constraints，那么一個對應的Authenticator會被創建

Context Parameters

從前面給出的 體系結構圖 中可以看出，Context Parameters特性只在Context中有支持。

如下的兩種配置等價，都是為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

從前面給出的 體系結構圖 中可以看出，Environment Entries特性在GlobalNamingResources和Context中都有支持。

如下的兩種配置等價，都是為配置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應用程序可見。如果換成Context則表示只對相應Web應用程序可見。

Resource Definitions

從前面給出的 體系結構圖 中可以看出，Resource Definitions特性在GlobalNamingResources和Context中都有支持。

如下的兩種配置等價，都是為定義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應用程序可見。如果換成Context則表示只對相應Web應用程序可見。

Resource Links

從前面給出的 體系結構圖 中可以看出，Resource Links特性在GlobalNamingResources和Context中都有支持。

ResourceLink 元素用來將資源從全局上下文(global context)中連接到每個Web應用的上下文(per-web-application contexts)中。使用方式依據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

從前面給出的 體系結構圖 中可以看出，Transaction特性在GlobalNamingResources和Context中都有支持。

通過在JNDI中查詢java:comp/UserTransaction可以得到UserTransaction的引用。

參考資料

Java Servlet
JavaServer Pages
JNDI Resources HOW-TO
The Valve Component
Tomcat中的職責鏈模式
Tomcat中的觀察者模式
Tomcat中的觀察者模式二
Tomcat中的策略模式
Tomcat中的TCP Server
The ClassLoader HowTo
Realm Configuration HOW-TO
置于文件系統之外的web應用程序

《Android開發完全講義（第2版）》（本書版權已輸出到臺灣）
http://product.dangdang.com/product.aspx?product_id=22741502

《Android高薪之路：Android程序員面試寶典》http://book.360buy.com/10970314.html

新浪微博：http://t.sina.com.cn/androidguy 昵稱：李寧_Lining

posted on 2008-10-12 22:56 銀河使者閱讀(2752) 評論(1) 編輯收藏所屬分類: java 、open source

# re: 圖解 Tomcat 體系結構 回復 更多評論

非常感謝你的分享

2009-03-31 14:44 | lishl

新用戶注冊刷新評論列表


只有注冊用戶登錄后才能發表評論。




網站導航: 博客園 IT新聞 Chat2DB C++博客博問管理
相關文章: Android開發（1）：隨機繪制彩色實心圓關于Android中傳遞數據的一些討論《Android/OPhone 開發完全講義》連載（10）：Sqlite數據庫《Android/OPhone開發完全講義》連載（8)：收到短信了，我該做點什么？《Android/OPhone開發完全講義》連載（7)：使用SharedPreferences存取復雜數據實用Android開發工具和資源精選中國移動開發者社區專訪：學習Android的兩大法寶可循環顯示圖像的Android Gallery組件移動互聯網的新寵：Android之繽紛世界《人人都玩開心網：Ext JS+Android+SSH整合開發Web與移動SNS》銷售排名第4，發篇ExtJS的文章(拖放樹結點)慶祝下

《Android開發完全講義（第2版）》（本書版權已輸出到臺灣）

《Android高薪之路：Android程序員面試寶典 》http://book.360buy.com/10970314.html

評論

# re: 圖解 Tomcat 體系結構 回復 更多評論

導航

公告

常用鏈接

留言簿(126)

我參與的團隊

隨筆分類(818)

隨筆檔案(310)

文章分類(1)

文章檔案(8)

相冊

ADSL、3G查詢

CSDN

eclipse

ibm

Java EE

Linux

Web

云服務

代理網站

關注的網站

協議

喜歡的Blog

國內廣告平臺

圖書出版

在線培訓

開發工具

微博客戶端

手機鈴聲

操作系統

數學

文件格式

源碼資源

移動（Mobile）

編程語言

英語學習

最新隨筆

搜索

積分與排名

最新評論

閱讀排行榜

評論排行榜

《Android高薪之路：Android程序員面試寶典》http://book.360buy.com/10970314.html

# re: 圖解 Tomcat 體系結構回復更多評論

ADSL、3G查詢