Tomcat的系统架构(以Tomcat5为基础)
Tomcat總體設(shè)計(jì)
?????? Tomcat的總體結(jié)構(gòu)圖:
?
????? 由上圖可知,Tomcat有兩個(gè)核心組件:Connector和Container。Connector組件是可以被替換的,這樣可以給服務(wù)器設(shè)計(jì)者提供更多選擇,它非常重要。它不僅跟服務(wù)器本身設(shè)計(jì)相關(guān),而且和不同的應(yīng)用場(chǎng)景也很相關(guān),所以一個(gè)Container可以選擇對(duì)應(yīng)多個(gè)Connector。多個(gè)Connector與一個(gè)Container就形成了一個(gè)Service,這樣就可以對(duì)外提供服務(wù)了。但是Service還要有一個(gè)生存環(huán)境,必須能給其生命、掌握其生死大權(quán),這時(shí)就非Server莫屬了。所以整個(gè)Tomcat的生命周期由Server控制。
????? 1.以Service為媒介
?????? Service只是在Connector和Container外面多包了一層,把它們組裝在了一起,向外面提供服務(wù)。一個(gè)Service可以設(shè)置多個(gè)Connector,但是只能有一個(gè)Container容器。
這個(gè)Service接口的方法列表如下圖:
????? 從Service接口中定義的方法知道,它主要是為了關(guān)聯(lián)Connector和Container,同時(shí)會(huì)初始化它下面的其它組件(但不控制它們的生命周期)。在Tomcat中Service接口的標(biāo)準(zhǔn)實(shí)現(xiàn)類(lèi)是StandardService,它不僅實(shí)現(xiàn)了Service接口,同時(shí)還實(shí)現(xiàn)了Lifecycle接口,這樣它就可以控制下面組件的生命周期了。StandardService類(lèi)結(jié)構(gòu)圖如下:
?
????? 由上圖可知,除了Service接口的方法的實(shí)現(xiàn)以及控制組件生命周期的Lifecycle接口的實(shí)現(xiàn),還有幾個(gè)方法用于實(shí)現(xiàn)事件監(jiān)聽(tīng)方法。不僅是這個(gè)Service組件,在Tomcat中其它組件也同樣有這幾個(gè)方法。
????? 下面是StandardService中的幾個(gè)主要方法:
?????? ? ? ?
?????? 2.以Server為“居”
?????? 前面說(shuō)一對(duì)情侶因?yàn)?Service 而成為一對(duì)夫妻,有了能夠組成一個(gè)家庭的基本條件,但是它們還要有個(gè)實(shí)體的家,這是它們?cè)谏鐣?huì)上生存之本,有了家它們就可以安心的為人民服務(wù)了,一起為社會(huì)創(chuàng)造財(cái)富。
????? Server 要完成的任務(wù)很簡(jiǎn)單,就是要能夠提供一個(gè)接口讓其它程序能夠訪問(wèn)到這個(gè) Service 集合、同時(shí)要維護(hù)它所包含的所有 Service 的生命周期,包括如何初始化、如何結(jié)束服務(wù)、如何找到別人要訪問(wèn)的 Service。還有其它的一些次要的任務(wù),如您住在這個(gè)地方要向當(dāng)?shù)卣サ怯洶 ⒖赡苓€有要配合當(dāng)?shù)毓矙C(jī)關(guān)日常的安全檢查什么的。
????? Server 的類(lèi)結(jié)構(gòu)圖如下:
????? 它的標(biāo)準(zhǔn)實(shí)現(xiàn)類(lèi) StandardServer 實(shí)現(xiàn)了上面這些方法,同時(shí)也實(shí)現(xiàn)了 Lifecycle、MbeanRegistration 兩個(gè)接口的所有方法,下面主要看一下 StandardServer 重要的一個(gè)方法 addService 的實(shí)現(xiàn):
清單 3. StandardServer.addService
public void addService(Service service) {service.setServer(this);synchronized (services) {Service results[] = new Service[services.length + 1];System.arraycopy(services, 0, results, 0, services.length);results[services.length] = service;services = results;if (initialized) {try {service.initialize();} catch (LifecycleException e) {e.printStackTrace(System.err);}}if (started && (service instanceof Lifecycle)) {try {((Lifecycle) service).start();} catch (LifecycleException e) {;}}support.firePropertyChange("service", null, service);} }????? 從上面第一句就知道了 Service 和 Server 是相互關(guān)聯(lián)的,Server 也是和 Service 管理 Connector 一樣管理它,也是將 Service 放在一個(gè)數(shù)組中,后面部分的代碼也是管理這個(gè)新加進(jìn)來(lái)的 Service 的生命周期。Tomcat6 中也是沒(méi)有什么變化的。
?
????? 3.組件的生命線“Lifecycle”?????
?????? 前面一直在說(shuō) Service 和 Server 管理它下面組件的生命周期,那它們是如何管理的呢?
?????? Tomcat 中組件的生命周期是通過(guò) Lifecycle 接口來(lái)控制的,組件只要繼承這個(gè)接口并實(shí)現(xiàn)其中的方法就可以統(tǒng)一被擁有它的組件控制了,這樣一層一層的直到一個(gè)最高級(jí)的組件就可以控制 Tomcat 中所有組件的生命周期,這個(gè)最高的組件就是 Server,而控制 Server 的是 Startup,也就是您啟動(dòng)和關(guān)閉 Tomcat。
?????? 下面是 Lifecycle 接口的類(lèi)結(jié)構(gòu)圖:
????? 除了控制生命周期的 Start 和 Stop 方法外還有一個(gè)監(jiān)聽(tīng)機(jī)制,在生命周期開(kāi)始和結(jié)束的時(shí)候做一些額外的操作。這個(gè)機(jī)制在其它的框架中也被使用,如在 Spring 中。關(guān)于這個(gè)設(shè)計(jì)模式會(huì)在后面介紹。
????? Lifecycle 接口的方法的實(shí)現(xiàn)都在其它組件中,就像前面中說(shuō)的,組件的生命周期由包含它的父組件控制,所以它的 Start 方法自然就是調(diào)用它下面的組件的 Start 方法,Stop 方法也是一樣。如在 Server 中 Start 方法就會(huì)調(diào)用 Service 組件的 Start 方法,Server 的 Start 方法代碼如下:
?????? 清單 4. StandardServer.Start
public void start() throws LifecycleException {if (started) {log.debug(sm.getString("standardServer.start.started"));return;}lifecycle.fireLifecycleEvent(BEFORE_START_EVENT, null);lifecycle.fireLifecycleEvent(START_EVENT, null);started = true;synchronized (services) {for (int i = 0; i < services.length; i++) {if (services[i] instanceof Lifecycle)((Lifecycle) services[i]).start();}}lifecycle.fireLifecycleEvent(AFTER_START_EVENT, null); }???????監(jiān)聽(tīng)的代碼會(huì)包圍 Service 組件的啟動(dòng)過(guò)程,就是簡(jiǎn)單的循環(huán)啟動(dòng)所有 Service 組件的 Start 方法,但是所有 Service 必須要實(shí)現(xiàn) Lifecycle 接口,這樣做會(huì)更加靈活。
?????? Server 的 Stop 方法代碼如下:
清單 5. StandardServer.Stop
public void stop() throws LifecycleException {if (!started)return;lifecycle.fireLifecycleEvent(BEFORE_STOP_EVENT, null);lifecycle.fireLifecycleEvent(STOP_EVENT, null);started = false;for (int i = 0; i < services.length; i++) {if (services[i] instanceof Lifecycle)((Lifecycle) services[i]).stop();}lifecycle.fireLifecycleEvent(AFTER_STOP_EVENT, null); }?????? 它所要做的事情也和 Start 方法差不多。
?
?
Connector 組件
????? Connector 組件是 Tomcat 中兩個(gè)核心組件之一,它的主要任務(wù)是負(fù)責(zé)接收瀏覽器的發(fā)過(guò)來(lái)的 tcp 連接請(qǐng)求,創(chuàng)建一個(gè) Request 和 Response 對(duì)象分別用于和請(qǐng)求端交換數(shù)據(jù),然后會(huì)產(chǎn)生一個(gè)線程來(lái)處理這個(gè)請(qǐng)求并把產(chǎn)生的 Request 和 Response 對(duì)象傳給處理這個(gè)請(qǐng)求的線程,處理這個(gè)請(qǐng)求的線程就是 Container 組件要做的事了。
????? 由于這個(gè)過(guò)程比較復(fù)雜,大體的流程可以用下面的順序圖來(lái)解釋:
??????? 圖 6. Connector 處理一次請(qǐng)求順序圖
?
??????Tomcat5 中默認(rèn)的 Connector 是 Coyote,這個(gè) Connector 是可以選擇替換的。Connector 最重要的功能就是接收連接請(qǐng)求然后分配線程讓 Container 來(lái)處理這個(gè)請(qǐng)求,所以這必然是多線程的,多線程的處理是 Connector 設(shè)計(jì)的核心。Tomcat5 將這個(gè)過(guò)程更加細(xì)化,它將 Connector 劃分成 Connector、Processor、Protocol, 另外 Coyote 也定義自己的 Request 和 Response 對(duì)象。
????? 下面主要看一下 Tomcat 中如何處理多線程的連接請(qǐng)求,先看一下 Connector 的主要類(lèi)圖:
??????? 圖 7. Connector 的主要類(lèi)圖
????? 看一下 HttpConnector 的 Start 方法:
??????? 清單 6. HttpConnector.Start
public void start() throws LifecycleException {if (started)throw new LifecycleException(sm.getString("httpConnector.alreadyStarted"));threadName = "HttpConnector[" + port + "]";lifecycle.fireLifecycleEvent(START_EVENT, null);started = true;threadStart();while (curProcessors < minProcessors) {if ((maxProcessors > 0) && (curProcessors >= maxProcessors))break;HttpProcessor processor = newProcessor();recycle(processor);} }?????? threadStart() 執(zhí)行就會(huì)進(jìn)入等待請(qǐng)求的狀態(tài),直到一個(gè)新的請(qǐng)求到來(lái)才會(huì)激活它繼續(xù)執(zhí)行,這個(gè)激活是在 HttpProcessor 的 assign 方法中,這個(gè)方法是代碼如下?:
?????? 清單 7. HttpProcessor.assign
synchronized void assign(Socket socket) {while (available) {try {wait();} catch (InterruptedException e) {}}this.socket = socket;available = true;notifyAll();if ((debug >= 1) && (socket != null))log(" An incoming request is being assigned"); }????? 創(chuàng)建 HttpProcessor 對(duì)象是會(huì)把 available 設(shè)為 false,所以當(dāng)請(qǐng)求到來(lái)時(shí)不會(huì)進(jìn)入 while 循環(huán),將請(qǐng)求的 socket 賦給當(dāng)期處理的 socket,并將 available 設(shè)為 true,當(dāng) available 設(shè)為 true 是 HttpProcessor 的 run 方法將被激活,接下去將會(huì)處理這次請(qǐng)求。
????? Run 方法代碼如下:
?????? 清單 8. HttpProcessor.Run
public void run() { while (!stopped) { Socket socket = await(); if (socket == null) continue; try { process(socket); } catch (Throwable t) { log("process.invoke", t); } connector.recycle(this); } synchronized (threadSync) { threadSync.notifyAll(); } }????? 解析 socket 的過(guò)程在 process 方法中,process 方法的代碼片段如下:
?????? 清單 9. HttpProcessor.process
private void process(Socket socket) {boolean ok = true;boolean finishResponse = true;SocketInputStream input = null;OutputStream output = null;try {input = new SocketInputStream(socket.getInputStream(),connector.getBufferSize());} catch (Exception e) {log("process.create", e);ok = false;}keepAlive = true;while (!stopped && ok && keepAlive) {finishResponse = true;try {request.setStream(input);request.setResponse(response);output = socket.getOutputStream();response.setStream(output);response.setRequest(request);((HttpServletResponse) response.getResponse()).setHeader("Server", SERVER_INFO);} catch (Exception e) {log("process.create", e);ok = false;}try {if (ok) {parseConnection(socket);parseRequest(input, output);if (!request.getRequest().getProtocol().startsWith("HTTP/0"))parseHeaders(input);if (http11) {ackRequest(output);if (connector.isChunkingAllowed())response.setAllowChunking(true);}}。。。。。。try {((HttpServletResponse) response).setHeader("Date", FastHttpDateFormat.getCurrentDate());if (ok) {connector.getContainer().invoke(request, response);}。。。。。。}try {shutdownInput(input);socket.close();} catch (IOException e) {;} catch (Throwable e) {log("process.invoke", e);}socket = null; }????? 當(dāng) Connector 將 socket 連接封裝成 request 和 response 對(duì)象后接下來(lái)的事情就交給 Container 來(lái)處理了。
??? Servlet 容器“Container”
????? Container 是容器的父接口,所有子容器都必須實(shí)現(xiàn)這個(gè)接口,Container 容器的設(shè)計(jì)用的是典型的責(zé)任鏈的設(shè)計(jì)模式,它有四個(gè)子容器組件構(gòu)成,分別是:Engine、Host、Context、Wrapper,這四個(gè)組件不是平行的,而是父子關(guān)系,Engine 包含 Host,Host 包含 Context,Context 包含 Wrapper。通常一個(gè) Servlet class 對(duì)應(yīng)一個(gè) Wrapper,如果有多個(gè) Servlet 就可以定義多個(gè) Wrapper,如果有多個(gè) Wrapper 就要定義一個(gè)更高的 Container 了,如 Context,Context 通常就是對(duì)應(yīng)下面這個(gè)配置:
清單 10. Server.xml
<Context path="/library"docBase="D:\projects\library\deploy\target\library.war" reloadable="true" />????? 容器的總體設(shè)計(jì)
????? Context 還可以定義在父容器 Host 中,Host 不是必須的,但是要運(yùn)行 war 程序,就必須要 Host,因?yàn)?war 中必有 web.xml 文件,這個(gè)文件的解析就需要 Host 了,如果要有多個(gè) Host 就要定義一個(gè) top 容器 Engine 了。而 Engine 沒(méi)有父容器了,一個(gè) Engine 代表一個(gè)完整的 Servlet 引擎。
那么這些容器是如何協(xié)同工作的呢?先看一下它們之間的關(guān)系圖:
圖 8. 四個(gè)容器的關(guān)系圖
(查看清晰大圖)
????? 當(dāng) Connector 接受到一個(gè)連接請(qǐng)求時(shí),將請(qǐng)求交給 Container,Container 是如何處理這個(gè)請(qǐng)求的?這四個(gè)組件是怎么分工的,怎么把請(qǐng)求傳給特定的子容器的呢?又是如何將最終的請(qǐng)求交給 Servlet 處理。下面是這個(gè)過(guò)程的時(shí)序圖:
??????? 圖 9. Engine 和 Host 處理請(qǐng)求的時(shí)序圖
(查看清晰大圖)
????? 這里看到了 Valve 是不是很熟悉,沒(méi)錯(cuò) Valve 的設(shè)計(jì)在其他框架中也有用的,同樣 Pipeline 的原理也基本是相似的,它是一個(gè)管道,Engine 和 Host 都會(huì)執(zhí)行這個(gè) Pipeline,您可以在這個(gè)管道上增加任意的 Valve,Tomcat 會(huì)挨個(gè)執(zhí)行這些 Valve,而且四個(gè)組件都會(huì)有自己的一套 Valve 集合。您怎么才能定義自己的 Valve 呢?在 server.xml 文件中可以添加,如給 Engine 和 Host 增加一個(gè) Valve 如下:
????? 清單 11. Server.xml
<Engine defaultHost="localhost" name="Catalina"><Valve className="org.apache.catalina.valves.RequestDumperValve"/>………<Host appBase="webapps" autoDeploy="true" name="localhost" unpackWARs="true" xmlNamespaceAware="false" xmlValidation="false"><Valve className="org.apache.catalina.valves.FastCommonAccessLogValve"directory="logs" prefix="localhost_access_log." suffix=".txt"pattern="common" resolveHosts="false"/> …………</Host> </Engine>????? StandardEngineValve 和 StandardHostValve 是 Engine 和 Host 的默認(rèn)的 Valve,它們是最后一個(gè) Valve 負(fù)責(zé)將請(qǐng)求傳給它們的子容器,以繼續(xù)往下執(zhí)行。
前面是 Engine 和 Host 容器的請(qǐng)求過(guò)程,下面看 Context 和 Wrapper 容器時(shí)如何處理請(qǐng)求的。下面是處理請(qǐng)求的時(shí)序圖:
?????? 圖 10. Context 和 wrapper 的處理請(qǐng)求時(shí)序圖
(查看清晰大圖)
從 Tomcat5 開(kāi)始,子容器的路由放在了 request 中,request 中保存了當(dāng)前請(qǐng)求正在處理的 Host、Context 和 wrapper。
Engine 容器
Engine 容器比較簡(jiǎn)單,它只定義了一些基本的關(guān)聯(lián)關(guān)系,接口類(lèi)圖如下:
圖 11. Engine 接口的類(lèi)結(jié)構(gòu)
它的標(biāo)準(zhǔn)實(shí)現(xiàn)類(lèi)是 StandardEngine,這個(gè)類(lèi)注意一點(diǎn)就是 Engine 沒(méi)有父容器了,如果調(diào)用 setParent 方法時(shí)將會(huì)報(bào)錯(cuò)。添加子容器也只能是 Host 類(lèi)型的,代碼如下:
清單 12. StandardEngine. addChild
public void addChild(Container child) {if (!(child instanceof Host))throw new IllegalArgumentException(sm.getString("standardEngine.notHost"));super.addChild(child); }public void setParent(Container container) {throw new IllegalArgumentException(sm.getString("standardEngine.notParent")); }它的初始化方法也就是初始化和它相關(guān)聯(lián)的組件,以及一些事件的監(jiān)聽(tīng)。
Host 容器
Host 是 Engine 的子容器,一個(gè) Host 在 Engine 中代表一個(gè)虛擬主機(jī),這個(gè)虛擬主機(jī)的作用就是運(yùn)行多個(gè)應(yīng)用,它負(fù)責(zé)安裝和展開(kāi)這些應(yīng)用,并且標(biāo)識(shí)這個(gè)應(yīng)用以便能夠區(qū)分它們。它的子容器通常是 Context,它除了關(guān)聯(lián)子容器外,還有就是保存一個(gè)主機(jī)應(yīng)該有的信息。
下面是和 Host 相關(guān)的類(lèi)關(guān)聯(lián)圖:
圖 12. Host 相關(guān)的類(lèi)圖
(查看清晰大圖)
從上圖中除了所有容器都繼承的 ContainerBase 外,StandardHost 還實(shí)現(xiàn)了 Deployer 接口,上圖清楚的列出了這個(gè)接口的主要方法,這些方法都是安裝、展開(kāi)、啟動(dòng)和結(jié)束每個(gè) web application。
Deployer 接口的實(shí)現(xiàn)是 StandardHostDeployer,這個(gè)類(lèi)實(shí)現(xiàn)了的最重要的幾個(gè)方法,Host 可以調(diào)用這些方法完成應(yīng)用的部署等。
Context 容器
Context 代表 Servlet 的 Context,它具備了 Servlet 運(yùn)行的基本環(huán)境,理論上只要有 Context 就能運(yùn)行 Servlet 了。簡(jiǎn)單的 Tomcat 可以沒(méi)有 Engine 和 Host。
Context 最重要的功能就是管理它里面的 Servlet 實(shí)例,Servlet 實(shí)例在 Context 中是以 Wrapper 出現(xiàn)的,還有一點(diǎn)就是 Context 如何才能找到正確的 Servlet 來(lái)執(zhí)行它呢? Tomcat5 以前是通過(guò)一個(gè) Mapper 類(lèi)來(lái)管理的,Tomcat5 以后這個(gè)功能被移到了 request 中,在前面的時(shí)序圖中就可以發(fā)現(xiàn)獲取子容器都是通過(guò) request 來(lái)分配的。
Context 準(zhǔn)備 Servlet 的運(yùn)行環(huán)境是在 Start 方法開(kāi)始的,這個(gè)方法的代碼片段如下:
清單 13. StandardContext.start
public synchronized void start() throws LifecycleException {………if( !initialized ) { try {init();} catch( Exception ex ) {throw new LifecycleException("Error initializaing ", ex);}}………lifecycle.fireLifecycleEvent(BEFORE_START_EVENT, null);setAvailable(false);setConfigured(false);boolean ok = true;File configBase = getConfigBase();if (configBase != null) {if (getConfigFile() == null) {File file = new File(configBase, getDefaultConfigFile());setConfigFile(file.getPath());try {File appBaseFile = new File(getAppBase());if (!appBaseFile.isAbsolute()) {appBaseFile = new File(engineBase(), getAppBase());}String appBase = appBaseFile.getCanonicalPath();String basePath = (new File(getBasePath())).getCanonicalPath();if (!basePath.startsWith(appBase)) {Server server = ServerFactory.getServer();((StandardServer) server).storeContext(this);}} catch (Exception e) {log.warn("Error storing config file", e);}} else {try {String canConfigFile = (new File(getConfigFile())).getCanonicalPath();if (!canConfigFile.startsWith (configBase.getCanonicalPath())) {File file = new File(configBase, getDefaultConfigFile());if (copy(new File(canConfigFile), file)) {setConfigFile(file.getPath());}}} catch (Exception e) {log.warn("Error setting config file", e);}}}………Container children[] = findChildren();for (int i = 0; i < children.length; i++) {if (children[i] instanceof Lifecycle)((Lifecycle) children[i]).start();}if (pipeline instanceof Lifecycle)((Lifecycle) pipeline).start();………}它主要是設(shè)置各種資源屬性和管理組件,還有非常重要的就是啟動(dòng)子容器和 Pipeline。
我們知道 Context 的配置文件中有個(gè) reloadable 屬性,如下面配置:
清單 14. Server.xml
<Context path="/library" docBase="D:\projects\library\deploy\target\library.war" reloadable="true" />當(dāng)這個(gè) reloadable 設(shè)為 true 時(shí),war 被修改后 Tomcat 會(huì)自動(dòng)的重新加載這個(gè)應(yīng)用。如何做到這點(diǎn)的呢 ? 這個(gè)功能是在 StandardContext 的 backgroundProcess 方法中實(shí)現(xiàn)的,這個(gè)方法的代碼如下:
清單 15. StandardContext. backgroundProcess
public void backgroundProcess() {if (!started) return;count = (count + 1) % managerChecksFrequency;if ((getManager() != null) && (count == 0)) {try {getManager().backgroundProcess();} catch ( Exception x ) {log.warn("Unable to perform background process on manager",x);}}if (getLoader() != null) {if (reloadable && (getLoader().modified())) {try {Thread.currentThread().setContextClassLoader(StandardContext.class.getClassLoader());reload();} finally {if (getLoader() != null) {Thread.currentThread().setContextClassLoader(getLoader().getClassLoader());}}}if (getLoader() instanceof WebappLoader) {((WebappLoader) getLoader()).closeJARs(false);}} }它會(huì)調(diào)用 reload 方法,而 reload 方法會(huì)先調(diào)用 stop 方法然后再調(diào)用 Start 方法,完成 Context 的一次重新加載。可以看出執(zhí)行 reload 方法的條件是 reloadable 為 true 和應(yīng)用被修改,那么這個(gè) backgroundProcess 方法是怎么被調(diào)用的呢?
這個(gè)方法是在 ContainerBase 類(lèi)中定義的內(nèi)部類(lèi) ContainerBackgroundProcessor 被周期調(diào)用的,這個(gè)類(lèi)是運(yùn)行在一個(gè)后臺(tái)線程中,它會(huì)周期的執(zhí)行 run 方法,它的 run 方法會(huì)周期調(diào)用所有容器的 backgroundProcess 方法,因?yàn)樗腥萜鞫紩?huì)繼承 ContainerBase 類(lèi),所以所有容器都能夠在 backgroundProcess 方法中定義周期執(zhí)行的事件。
Wrapper 容器
Wrapper 代表一個(gè) Servlet,它負(fù)責(zé)管理一個(gè) Servlet,包括Servlet 的裝載、初始化、執(zhí)行以及資源回收。Wrapper 是最底層的容器,它沒(méi)有子容器了,所以調(diào)用它的 addChild 將會(huì)報(bào)錯(cuò)。
Wrapper 的實(shí)現(xiàn)類(lèi)是 StandardWrapper,StandardWrapper 還實(shí)現(xiàn)了擁有一個(gè) Servlet 初始化信息的 ServletConfig,由此看出 StandardWrapper 將直接和 Servlet 的各種信息打交道。
下面看一下非常重要的一個(gè)方法 loadServlet,代碼片段如下:
清單 16. StandardWrapper.loadServlet
public synchronized Servlet loadServlet() throws ServletException {………Servlet servlet;try {………ClassLoader classLoader = loader.getClassLoader();………Class classClass = null;………servlet = (Servlet) classClass.newInstance();if ((servlet instanceof ContainerServlet) &&(isContainerProvidedServlet(actualClass) ||((Context)getParent()).getPrivileged() )) {((ContainerServlet) servlet).setWrapper(this);}classLoadTime=(int) (System.currentTimeMillis() -t1);try {instanceSupport.fireInstanceEvent(InstanceEvent.BEFORE_INIT_EVENT,servlet);if( System.getSecurityManager() != null) {Class[] classType = new Class[]{ServletConfig.class};Object[] args = new Object[]{((ServletConfig)facade)};SecurityUtil.doAsPrivilege("init",servlet,classType,args);} else {servlet.init(facade);}if ((loadOnStartup >= 0) && (jspFile != null)) {………if( System.getSecurityManager() != null) {Class[] classType = new Class[]{ServletRequest.class,ServletResponse.class};Object[] args = new Object[]{req, res};SecurityUtil.doAsPrivilege("service",servlet,classType,args);} else {servlet.service(req, res);}}instanceSupport.fireInstanceEvent(InstanceEvent.AFTER_INIT_EVENT,servlet);………return servlet; }它基本上描述了對(duì) Servlet 的操作,當(dāng)裝載了 Servlet 后就會(huì)調(diào)用 Servlet 的 init 方法,同時(shí)會(huì)傳一個(gè) StandardWrapperFacade 對(duì)象給 Servlet,這個(gè)對(duì)象包裝了 StandardWrapper,ServletConfig 與它們的關(guān)系圖如下:
圖 13. ServletConfig 與 StandardWrapperFacade、StandardWrapper 的關(guān)系
Servlet 可以獲得的信息都在 StandardWrapperFacade 封裝,這些信息又是在 StandardWrapper 對(duì)象中拿到的。所以 Servlet 可以通過(guò) ServletConfig 拿到有限的容器的信息。
當(dāng) Servlet 被初始化完成后,就等著 StandardWrapperValve 去調(diào)用它的 service 方法了,調(diào)用 service 方法之前要調(diào)用 Servlet 所有的 filter。
?
轉(zhuǎn)載于:https://www.cnblogs.com/xbj-2016/p/5910817.html
總結(jié)
以上是生活随笔為你收集整理的Tomcat的系统架构(以Tomcat5为基础)的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇: 微信上的零钱通安全吗
- 下一篇: 启动tomcat提示Could not