Tomcat源碼組織結構

Tomcat 源碼組織結構

目錄結構

這裏所介紹的目錄結構，是使用CATALINA-BASE變量定義的路徑，若是沒有經過配置多個CATALINA-BASE目錄來使用多實例，則CATALINA-BASE和CATALINA-HOME值相同，也就是tomcat安裝的目錄。

推薦使用的關鍵點，就是將源碼層次結構和生產部署的應用程序層次結構分開，這種分開有如下幾個好處：

1. 在源碼目錄裏面的內容，能夠簡單的修改、移動、打包，由於可執行的應用程序版本並不在該目錄中；
2. 源碼目錄更好被控制，由於裏面只有源碼
3. 當須要將應用程序發佈出去再創建一個實例，分開布放會更簡單

Ant開發工具，就是用來建立和處理這些層次結構的。

對於管理員來講，用來控制應用程序源碼的目錄和文件層次可能更有吸引力，因此，下面要講介紹的組織會更適用。使用的配置文件也就是build.xml文件，在源碼目錄下的根節點，如下的這些目錄都是存在的：

1. docs目錄，用來存放應用程序的文件，
2. src目錄，用來建立程序的java源碼、封裝bean或者是隻有該實例應用程序纔會使用的單獨的Java類，若是源碼被封裝在一個壓縮包裏面，則壓縮包裏面的層次結構，必須和該目錄下的目錄結構對應
3. web目錄，web站點的靜態資源內容，JSP和JS、CSS樣式文件和圖像，這些資源都會被client直接訪問到，這個站點，是web應用程序的根目錄站點，而後這個目錄下的全部子目錄結構，都會對應到訪問這些文件的URL上面
4. web/web-inf目錄，應用程序所需的特殊的配置文件，包含站點部署的xml文件，本身建立的用戶標記庫的標記描述文件，和其餘但願在站點中被訪問的資源，這個站點至關於web應用程序根目錄的子目錄，可是程序配置文件不容許client直接訪問該目錄下的內容。也就是說，這個目錄下能夠用來存放一些敏感信息，只用於應用程序，好比數據庫鏈接器的參數

在開發環境中，會有兩個單獨的目錄

1. build目錄，當執行默認的build程序時，也就是執行ant，目錄中就會包含應用程序壓縮包中的完整的文件鏡像，tomcat容許直接使用未解壓的目錄來部署應用程序，不須要將這些內容，拷貝到 $CATALINA_BASE/webapps目錄下，或者是經過manager來安裝程序。這種方式，在開發環境中特別適用。
2. dist目錄，當在執行ant dist時，會建立該目錄，會建立一個應用程序的實時二進制文件鏡像，包含受權信息、文檔等其餘文件。

這倆目錄不能是壓縮包的形式，由於在開發部署的過程當中，這倆目錄是會被刪除和被建立的，正由於這個緣由，若是是爲了維護性能來記錄變化，不容許編輯這倆目錄下的 任何源文件，由於這些優化會在下一次編譯的時候丟失。

外部依賴

當應用程序須要一個其餘的jar文件或者其餘資源時，而這些資源來源於其餘外部的工程或者是包，最簡單的例子，當應用程序須要使用一個數據源，也就是須要一個JDBC驅動器。

不一樣的開發人員，會選擇使用不一樣的合適的方法來解決這個問題，有一些人會推薦將所依賴的jar文件進行一次拷貝，而後複製到全部須要改jar文件的應用程序的源碼控制壓縮包中，然而當在多個應用程序中使用同一個jar文件時，當須要對這個jar文件進行更新時，這就須要對多個位置的文件進行更新。

所以，就會推薦不將該文件拷貝到應用程序的源碼壓縮包裏面，替換的方法是將該外部依賴包集成到應用程序的編譯過程當中。經過這種方法，只須要選擇合適版本的jar文件，而不須要在當jar文件發生更新時，去擔憂應用程序。

好比ant build.xml文件時，須要指定須要拷貝文件的位置，當這些文件發生改變時，不須要修改build.xml，這些編譯參數能夠基於每個應用程序集進行自定義，或者是使用家目錄下的默認標準編譯參數。

在不少狀況下，系統開發人員已經在tomcat的lib目錄下安裝了所需的jar文件，根本不須要作其餘的操做，build.xml中自動就包含了這些文件的完整路徑。

 

源碼控制

正如以前提到的，強烈推薦將組成應用系統的源碼，存放在一個相似於CVS的源碼控制系統中，若是選擇這麼作，在源碼層次中的每個目錄和文件都應該被登記和保存，可是不會產生新的文件，若是註冊了二進制文件，同時須要向源碼控制系統說明。

建議不要將build和dist目錄下的文件保存在源碼控制系統中，一個簡單的方法來告訴CVS系統去忽略這些目錄，是在源碼根目錄中指定一個.cvxignore文件，內容包含build和dist便可。

 

編譯XML配置文件

在tomcat中，會使用ant來管理java源碼文件的兼容性，同時建立實施的層次結構，ant的操做是在一個名爲build.xml的配置文件的控制下進行的，該文件中定義了須要操做的步驟，該文件存放在源碼層次結構的根部木了下，在源碼控制系統中會被檢查。

和其餘編譯文件相似，build.xml提供了許多參數，來支持其餘的開發活動，好比建立相關聯的java文檔，清空開發環境家目錄，爲應用程序打包分發到其餘地方，一個好的build.xml中應該包含內部註釋，描述這些參數的功能，經過ant -projecthelp來顯示工程文檔，改變目錄中包含的內容和格式。

從頭開始，基礎的build.xml文件，讓應用程序能夠被自定義和安裝源碼目錄，在該文件中描述了能夠執行的多種參數，一般包含如下幾個：

1. clean，會刪除已經存在的build和dist目錄，能夠經過擦除來從新創建，這能夠保證不會對源碼作改變，防止出現兼容性問題；
2. compile，該參數用來編譯全部變動的源碼，會在build目錄下的子目錄web-inf/classes中建立結果類文件，並且應用程序的結構文件也是精確的，在開發過程當中，這條命令是最頻繁被使用的，因此一般是默認的參數；
3. all，這個參數是先執行clean，後執行compile，這能夠保證對整個應用程序進行了編譯，保證不會有未知的兼容性問題。
4. dist，該參數會爲當前的應用程序產生一個副本，包含全部相關的文檔、javadoc，而後將應用程序壓縮包傳遞給相關係統進行部署，這個參數以來與deploy參數，應用程序的壓縮包一樣會將部署時間的全部外部依賴進行打包；
5. Javadoc，該參數會將整個web應用程序中的java類建立javadoc API文檔，假設在build.xml須要在應用發佈的時候包含全部的API文檔，使用這個參數，就會在dist目錄下建立一個子目錄，將這些文檔所有生成。正常在每次編譯過程當中是不須要產生這些文檔的，這個參數是一個獨立的參數，並非貶義的參數；
6. Install，該參數是告訴tomcat，如今操做的應用程序在部署完成後就能夠當即被使用，在這個過程當中，是不須要tomcat重啓的，可是這個參數也是一次性的，下一次tomcat重啓的時候不會再使用
7. Reload，一旦應用程序已經被安裝上以後，能夠經過compile參數繼續更新和變動，tomcat會自動的識別jsp頁面的變動，可是不能識別其餘內容，這個參數是用來告訴tomcat來重啓當前已經被安裝的應用程序，以便識別這些更新
8. Remove，