|
接上一篇，說到XmlConfiguration ,XmlConfiguration 利用自己實(shí)現(xiàn)的 IOC 組裝 Server 的全過程如下圖所示：
 這里可以看到 3 個關(guān)鍵的配置文件， jetty.xml 、 jetty-deploy.xml 、以及 contexts/xxx.xmll Jetty.xml 文件中定義了入口類 Server, 以及其所需要的線程池、 Connector 、 Handler 。 l Jetty-deploy.xml 中則定義了部署 web 應(yīng)用用到部署工具，在其中指定了部署 web 應(yīng)用的兩種方式，類似于 tomcat, 如果采用 webappProvider ，則表示將 web 應(yīng)用放在 webapp下即可生效，如果采用 ContextProvider ，則需要定義 Contexts 目錄所在位置，只要在該目錄下放置任何應(yīng)用的 context 配置文件就可以生效。 l Xxx.xml 這是一個用戶自定義文件，表示采用 ContextProvider 時，在其中定義一個WebAppContext 的 handler, 它指定了我們應(yīng)用所在的位置，便于加載。
XmlConfiguration 解析裝配完畢之后，就開始啟動服務(wù)， Jetty 的啟動是從 Server 開始的，我們來看一下服務(wù)器真正的啟動過程。
從上圖中我們能大概看出服務(wù)器啟動過程，先是由用戶設(shè)置好需要的核心組件，然后調(diào)用 Server.start() 開始啟動服務(wù)，其中會首先啟動 handler 處理器，之后啟動用戶自定義組件，這個自定義組件需要實(shí)現(xiàn) LifeCyle 接口，最后才啟動 Connector 接受請求。可以想到，關(guān)閉過程恰好是反過來，首先關(guān)閉接受請求的 connector ，然后再關(guān)閉用戶自定義組件，最后關(guān)閉 handler. 我們再來詳細(xì)看一下 Server 源代碼的核心實(shí)現(xiàn)過程，當(dāng)調(diào)用 start 方法時，其實(shí)是調(diào)用其祖先類 AbstractLifeCycle 中方法，該方法在這里有一個模板實(shí)現(xiàn)，如下：
看下 Connector 的詳細(xì)啟動過程： ( 以 NIO 為例 )
NIOConnector 啟動過程中，先創(chuàng)建了多個 SelectSet 對象，每個 SelectSet 負(fù)責(zé)一個 NIO 的 Selector ，專門用于監(jiān)聽 read 事件 ( 這里利用的多線程 Reactor 模式， http://gee.cs./dl/cpjslides/nio.pdf ) ，當(dāng)然這里僅僅是創(chuàng)建了對象，并沒有啟動，后面會提到。 SelectorManager ：
然后再調(diào)用 open 創(chuàng)建了一個 blocking 的阻塞 channel ，專門用于接受用戶的新連接，我們看下：
隨后從線程池中分配了 N 個 ( 可以在配置文件中配置 ) 線程用于啟動 SelectSet 監(jiān)聽 read 事件。
 最后再分配 1 個線程用于 accept 用戶的新連接，新連接來之后，會將其設(shè)置為 nonblocking 模式，之后就將其 Register給某個 SelectSet 去監(jiān)聽 read 事件，然后又返回來繼續(xù)監(jiān)聽新連接：
 Jetty 將所有的真正處理請求的動作都抽象成了 Handler ，因此做事情的組件都是實(shí)現(xiàn)了這個接口的，包括上圖所示的 WebAppContext 等等，需要做什么樣的工作，那么就添加什么樣的 Handler ，這里 SessionHandler 不是必須的，但是默認(rèn)是創(chuàng)建好的。 ServletHandler 主要負(fù)責(zé)處理 web 應(yīng)用的 Servlet 、 Filter 等工作，最后將請求直接交給 Servlet 、 Filter 都是在這里完成。這里展示的 Handler 的啟動過程其實(shí)是在準(zhǔn)備 web 應(yīng)用環(huán)境，例如解析 web 應(yīng)用的web.xml 等等工作，做好一切準(zhǔn)備工作。 |
|
|
