tomcat詳解及其配置

時間 2019-11-19

原文原文鏈接

　Tomcat 服務器是一個免費的開放源代碼的Web 應用服務器，目前最新版本是6.0.20(截止到2009-10-22)。html

　　Tomcat是Apache 軟件基金會（Apache Software Foundation）的Jakarta 項目中的一個核心項目，由Apache、Sun 和其餘一些公司及我的共同開發而成。因爲有了Sun 的參與和支持，最新的Servlet 和JSP 規範老是能在Tomcat 中獲得體現，Tomcat 5 支持最新的Servlet 2.4 和JSP 2.0 規範。由於Tomcat 技術先進、性能穩定，並且免費，於是深受Java 愛好者的喜好並獲得了部分軟件開發商的承認，成爲目前比較流行的Web 應用服務器。java

　　Tomcat 很受廣大程序員的喜歡，由於它運行時佔用的系統資源小，擴展性好，支持負載平衡與郵件服務等開發應用系統經常使用的功能；並且它還在不斷的改進和完善中，任何一個感興趣的程序員均可以更改它或在其中加入新的功能。程序員

　　Tomcat 是一個小型的輕量級應用服務器，在中小型系統和併發訪問用戶不是不少的場合下被廣泛使用，是開發和調試JSP 程序的首選。對於一個初學者來講，能夠這樣認爲，當在一臺機器上配置好Apache 服務器，可利用它響應對HTML 頁面的訪問請求。實際上Tomcat 部分是Apache 服務器的擴展，但它是獨立運行的，因此當你運行tomcat 時，它實際上做爲一個與Apache 獨立的進程單獨運行的。 web

　　這裏的訣竅是，當配置正確時，Apache 爲HTML頁面服務，而Tomcat 實際上運行JSP 頁面和Servlet。另外，Tomcat和IIS、Apache等Web服務器同樣，具備處理HTML頁面的功能，另外它仍是一個Servlet和JSP容器，獨立的Servlet容器是Tomcat的默認模式。不過，Tomcat處理靜態HTML的能力不如Apache服務器。 shell

Tomcat配置的10個技巧數據庫

　　1. 配置系統管理（Admin Web Application）apache

　　大多數商業化的J2EE服務器都提供一個功能強大的管理界面，且大都採用易於理解的Web應用界面。Tomcat按照本身的方式，一樣提供一個成熟的管理工具，而且絲絕不遜於那些商業化的競爭對手。Tomcat的Admin Web Application最初在4.1版本時出現，當時的功能包括管理context、data source、user和group等。固然也能夠管理像初始化參數，user、group、role的多種數據庫管理等。在後續的版本中，這些功能將得到很大的擴展，但現有的功能已經很是實用了。瀏覽器

　　Admin Web Application被定義在自動部署文件：CATALINA_BASE/webapps/admin.xml 。tomcat

　　必須編輯這個文件，以肯定Context中的docBase參數是絕對路徑。也就是說， CATALINA_BASE/webapps/admin.xml 的路徑是絕對路徑。做爲另一種選擇，也能夠刪除這個自動部署文件，而在server.xml文件中創建一個Admin Web Application的context，效果是同樣的。不能管理Admin Web Application這個應用，換而言之，除了刪除CATALINA_BASE/webapps/admin.xml ，可能什麼都作不了。安全

　　若是使用UserDatabaseRealm（默認），將須要添加一個user以及一個role到CATALINA_BASE/conf/tomcat-users.xml 文件中。你編輯這個文件，添加一個名叫「admin」的role 到該文件中，以下：

　　一樣須要有一個用戶，而且這個用戶的角色是「admin」。象存在的用戶那樣，添加一個用戶（改變密碼使其更加安全）：

　　當完成這些步驟後，請從新啓動Tomcat，訪問http://localhost:8080/admin，將看到一個登陸界面。Admin Web Application採用基於容器管理的安全機制，並採用了Jakarta Struts框架。一旦做爲「admin」角色的用戶登陸管理界面，將可以使用這個管理界面配置Tomcat。

　　2.配置應用管理（Manager Web Application）

　　Manager Web Application讓你經過一個比Admin Web Application更爲簡單的用戶界面，執行一些簡單的Web應用任務。

　　Manager Web Application被被定義在一個自動部署文件中：

　　CATALINA_BASE/webapps/manager.xml 。

　　必須編輯這個文件，以確保context的docBase參數是絕對路徑，也就是說CATALINA_HOME/server/webapps/manager的絕對路徑。

　　若是使用的是UserDatabaseRealm，那麼須要添加一個角色和一個用戶到CATALINA_BASE/conf/tomcat-users.xml文件中。接下來，編輯這個文件，添加一個名爲「manager」的角色到該文件中：

　　一樣須要有一個角色爲「manager」的用戶。像已經存在的用戶那樣，添加一個新用戶（改變密碼使其更加安全）：

　　而後從新啓動Tomcat，訪問http://localhost/manager/list，將看到一個很樸素的文本型管理界面，或者訪問http: //localhost/manager/html/list，將看到一個HMTL的管理界面。無論是哪一種方式都說明你的Manager Web Application如今已經啓動了。

　　Manager application能夠在沒有系統管理特權的基礎上，安裝新的Web應用，以用於測試。若是咱們有一個新的web應用位於 /home/user/hello下在，而且想把它安裝到 /hello下，爲了測試這個應用，能夠這麼作，在第一個文件框中輸入「/hello」（做爲訪問時的path），在第二個文本框中輸入「file: /home/user/hello」（做爲Config URL）。

　　Manager application還容許中止、從新啓動、移除以及從新部署一個web應用。中止一個應用使其沒法被訪問，當有用戶嘗試訪問這個被中止的應用時，將看到一個503的錯誤——「503 - This application is not currently available」。

　　移除一個web應用，只是指從Tomcat的運行拷貝中刪除了該應用，若是從新啓動Tomcat，被刪除的應用將再次出現（也就是說，移除並非指從硬盤上刪除）。

　　3.部署一個web應用

　　有兩個辦法能夠在系統中部署web服務。

　　1> 拷貝WAR文件或者web應用文件夾（包括該web的全部內容）到$CATALINA_BASE/webapps目錄下。

　　2> 爲web服務創建一個只包括context內容的XML片段文件，並把該文件放到$CATALINA_BASE/webapps目錄下。這個web應用自己能夠存儲在硬盤上的任何地方。

　　若是有一個WAR文件，想部署它，則只須要把該文件簡單的拷貝到CATALINA_BASE/webapps目錄下便可，文件必須以「。war」做爲擴展名。一旦Tomcat監聽到這個文件，它將（缺省的）解開該文件包做爲一個子目錄，並以WAR文件的文件名做爲子目錄的名字。接下來，Tomcat 將在內存中創建一個context，就好象在server.xml文件裏創建同樣。固然，其餘必需的內容，將從server.xml中的 DefaultContext得到。

　　部署web應用的另外一種方式是寫一個Context XML片段文件，而後把該文件拷貝到CATALINA_BASE/webapps目錄下。一個Context片段並不是一個完整的XML文件，而只是一個 context元素，以及對該應用的相應描述。這種片段文件就像是從server.xml中切取出來的context元素同樣，因此這種片段被命名爲「context片段」。

　　舉個例子，若是咱們想部署一個名叫MyWebApp.war的應用，該應用使用realm做爲訪問控制方式，咱們可使用下面這個片段：

<!--

　　Context fragment for deploying MyWebApp.war

　　-->

　　<Context path=「/demo」 docBase=「webapps/MyWebApp.war」

　　debug=「0」 privileged=「true」>

　　<Realm className=「org.apache.catalina.realm.UserDatabaseRealm」

　　resourceName=「UserDatabase」/>

　　</Context>

　　把該片段命名爲「MyWebApp.xml」，而後拷貝到CATALINA_BASE/webapps目錄下。

　　這種context片段提供了一種便利的方法來部署web應用，不須要編輯server.xml，除非想改變缺省的部署特性，安裝一個新的web應用時不須要重啓動Tomcat。

　　4.配置虛擬主機（Virtual Hosts）

　　關於server.xml中「Host」這個元素，只有在設置虛擬主機的才須要修改。虛擬主機是一種在一個web服務器上服務多個域名的機制，對每一個域名而言，都好象獨享了整個主機。實際上，大多數的小型商務網站都是採用虛擬主機實現的，這主要是由於虛擬主機能直接鏈接到Internet並提供相應的帶寬，以保障合理的訪問響應速度，另外虛擬主機還能提供一個穩定的固定IP。

　　基於名字的虛擬主機能夠被創建在任何web服務器上，創建的方法就是經過在域名服務器（DNS）上創建IP地址的別名，而且告訴web服務器把去往不一樣域名的請求分發到相應的網頁目錄。

　　在Tomcat中使用虛擬主機，須要設置DNS或主機數據。爲了測試，爲本地IP設置一個IP別名就足夠了，接下來，你須要在server.xml中添加幾行內容，以下：

　　<Connector className=「org.apache.coyote.tomcat4.CoyoteConnector」

　　port=「8080」 minProcessors=「5」 maxProcessors=「75」

　　enableLookups=「true」 redirectPort=「8443」/>

　　<Connector className=「org.apache.coyote.tomcat4.CoyoteConnector」

　　port=「8443」 minProcessors=「5」 maxProcessors=「75」

　　acceptCount=「10」 debug=「0」 scheme=「https」 secure=「true」/>

　　<Factory className=「org.apache.coyote.tomcat4.CoyoteServerSocketFactory」

　　clientAuth=「false」 protocol=「TLS」 />

　　</Connector>

　　<Host name=「localhost」 debug=「0」 appBase=「webapps」

　　unpackWARs=「true」 autoDeploy=「true」>

　　<Context path=「/orders」 docBase=「/home/ian/orders」 debug=「0」

　　reloadable=「true」 crossContext=「true」>

　　</Context>

　　</Host>

　　</Host>

　　</Engine>

　　</Service>

　　</Server>

　　Tomcat的server.xml文件，在初始狀態下，只包括一個虛擬主機，可是它容易被擴充到支持多個虛擬主機。在前面的例子中展現的是一個簡單的 server.xml版本，其中粗體部分就是用於添加一個虛擬主機。每個Host元素必須包括一個或多個context元素，所包含的context元素中必須有一個是默認的context，這個默認的context的顯示路徑應該爲空（例如，path=「」）。

　　5.配置基礎驗證（Basic Authentication）

　　容器管理驗證方法控制着當用戶訪問受保護的web應用資源時，如何進行用戶的身份鑑別。當一個web應用使用了Basic Authentication（BASIC參數在web.xml文件中auto-method元素中設置），而有用戶訪問受保護的web應用時， Tomcat將經過HTTP Basic Authentication方式，彈出一個對話框，要求用戶輸入用戶名和密碼。在這種驗證方法中，全部密碼將被以64位的編碼方式在網絡上傳輸。

　　注意：使用Basic Authentication經過被認爲是不安全的，由於它沒有強健的加密方法，除非在客戶端和服務器端都使用HTTPS或者其餘密碼加密碼方式（好比，在一個虛擬私人網絡中）。若沒有額外的加密方法，網絡管理員將可以截獲（或濫用）用戶的密碼。可是，若是是剛開始使用Tomcat，或者你想在你的 web應用中測試一下基於容器的安全管理，Basic Authentication仍是很是易於設置和使用的。只須要添加<security-constraint>和<login- config>兩個元素到web應用的web.xml文件中，而且在CATALINA_BASE/conf/tomcat-users.xml 文件中添加適當的<role>和<user>便可，而後從新啓動Tomcat。

　　6.配置單點登陸（Single Sign-On）

　　一旦設置了realm和驗證的方法，就須要進行實際的用戶登陸處理。通常說來，對用戶而言登陸系統是一件很麻煩的事情，必須儘可能減小用戶登陸驗證的次數。做爲缺省的狀況，當用戶第一次請求受保護的資源時，每個web應用都會要求用戶登陸。若是運行了多個web應用，而且每一個應用都須要進行單獨的用戶驗證，那這看起來就有點像在用戶搏鬥。用戶們不知道怎樣才能把多個分離的應用整合成一個單獨的系統，全部用戶也就不知道他們須要訪問多少個不同的應用，只是很迷惑，爲何總要不停的登陸。

　　Tomcat 4的「single sign-on」特性容許用戶在訪問同一虛擬主機下全部web應用時，只需登陸一次。爲了使用這個功能，只須要在Host上添加一個SingleSignOn Valve元素便可，以下所示：

　　<Valve className=「org.apache.catalina.authenticator.SingleSignOn」

　　debug=「0」/>

　　在Tomcat初始安裝後，server.xml的註釋裏面包括SingleSignOn Valve配置的例子，只須要去掉註釋，便可使用。那麼，任何用戶只要登陸過一個應用，則對於同一虛擬主機下的全部應用一樣有效。

　　使用single sign-on valve有一些重要的限制：

　　1> value必須被配置和嵌套在相同的Host元素裏，而且全部須要進行單點驗證的web應用（必須經過context元素定義）都位於該Host下。

　　2> 包括共享用戶信息的realm必須被設置在同一級Host中或者嵌套以外。

　　3> 不能被context中的realm覆蓋。

　　4> 使用單點登陸的web應用最好使用一個Tomcat的內置的驗證方式（被定義在web.xml中的<auth-method>中），這比自定義的驗證方式強，Tomcat內置的的驗證方式包括basic、digest、form和client-cert。

　　5> 若是你使用單點登陸，還但願集成一個第三方的web應用到你的網站中來，而且這個新的web應用使用它本身的驗證方式，而不使用容器管理安全，那你基本上就沒招了。用戶每次登陸原來全部應用時須要登陸一次，而且在請求新的第三方應用時還得再登陸一次。

　　6> 單點登陸須要使用cookies。

　　7.配置用戶定製目錄（Customized User Directores）

　　一些站點容許個別用戶在服務器上發佈網頁。例如，一所大學的學院可能想給每一位學生一個公共區域，或者是一個ISP但願給一些web空間給他的客戶，但這又不是虛擬主機。在這種狀況下，一個典型的方法就是在用戶名前面加一個特殊字符（~），做爲每位用戶的網站，好比：

　　http://www.cs.myuniversity.edu/~username提供兩種方法在主機上映射這些我的網站，主要使用一對特殊的Listener元素。Listener的className屬性應該是 org.apache.catalina.startup.UserConfig，userClass屬性應該是幾個映射類之一。若是電腦系統是 Unix，它將有一個標準的/etc/passwd文件，該文件中的賬號可以被運行中的Tomcat很容易的讀取，該文件指定了用戶的主目錄，使用 PasswdUserDatabase 映射類。

　　http://members.mybigisp.com/~username

　　Tomcat

　　<Listener className=「org.apache.catalina.startup.UserConfig」

　　directoryName=「public_html」

　　userClass=「org.apache.catalina.startup.PasswdUserDatabase」/>

　　web文件須要放置在像/home/users/ian/public_html 或者 /users/jbrittain/public_html同樣的目錄下面。固然你也能夠改變public_html 到其餘任何子目錄下。

　　實際上，這個用戶目錄根本不必定須要位於用戶主目錄下里面。若是你沒有一個密碼文件，但你又想把一個用戶名映射到公共的像/home同樣目錄的子目錄裏面，則可使用HomesUserDatabase類。

　　<Listener className=「org.apache.catalina.startup.UserConfig」

　　directoryName=「public_html」 homeBase=「/home」

　　userClass=「org.apache.catalina.startup.HomesUserDatabase」/>

　　這樣一來，web文件就能夠位於像/home/ian/public_html 或者 /home/jasonb/public_html同樣的目錄下。這種形式對Windows而言更加有利，你可使用一個像c:\home這樣的目錄。

　　這些Listener元素，若是出現，則必須在Host元素裏面，而不能在context元素裏面，由於它們都用應用於Host自己。

　　8.在Tomcat中使用CGI腳本

　　Tomcat主要是做爲Servlet/JSP容器，但它也有許多傳統web服務器的性能。支持通用網關接口（Common Gateway Interface，即CGI）就是其中之一，CGI提供一組方法在響應瀏覽器請求時運行一些擴展程序。CGI之因此被稱爲通用，是由於它能在大多數程序或腳本中被調用，包括：Perl，Python，awk，Unix shell scripting等，甚至包括Java。不會把一個Java應用程序看成CGI來運行，畢竟這樣太過原始。通常而言，開發Servlet總要比CGI具備更好的效率，由於當用戶點擊一個連接或一個按鈕時，不須要從操做系統層開始進行處理。

　　Tomcat包括一個可選的CGI Servlet，容許你運行遺留下來的CGI腳本。

　　爲了使Tomcat可以運行CGI，必須作的幾件事：

　　1. 把servlets-cgi.renametojar （在CATALINA_HOME/server/lib/目錄下）更名爲servlets-cgi.jar。處理CGI的servlet應該位於Tomcat的CLASSPATH下。

　　2. 在Tomcat的CATALINA_BASE/conf/web.xml 文件中，把關於<servlet-name> CGI的那段的註釋去掉（默認狀況下，該段位於第241行）。

　　3. 一樣，在Tomcat的CATALINA_BASE/conf/web.xml文件中，把關於對CGI進行映射的那段的註釋去掉（默認狀況下，該段位於第299行）。注意，這段內容指定了HTML連接到CGI腳本的訪問方式。

　　4. 能夠把CGI腳本放置在WEB-INF/cgi 目錄下（注意，WEB-INF是一個安全的地方，你能夠把一些不想被用戶看見或基於安全考慮不想暴露的文件放在此處），或者也能夠把CGI腳本放置在 context下的其餘目錄下，併爲CGI Servlet調整cgiPathPrefix初始化參數。這就指定的CGI Servlet的實際位置，且不能與上一步指定的URL重名。

　　5. 從新啓動Tomcat，你的CGI就能夠運行了。

　　在Tomcat中，CGI程序缺省放置在WEB-INF/cgi目錄下，正如前面所提示的那樣，WEB-INF目錄受保護的，經過客戶端的瀏覽器沒法窺探到其中內容，因此對於放置含有密碼或其餘敏感信息的CGI腳本而言，這是一個很是好的地方。爲了兼容其餘服務器，儘管你也能夠把CGI腳本保存在傳統的 /cgi-bin目錄，但要知道，在這些目錄中的文件有可能被網上好奇的衝浪者看到。另外，在Unix中，請肯定運行Tomcat的用戶有執行CGI腳本的權限。

　　　9.改變Tomcat中的JSP編譯器（JSP Compiler）

　　在Tomcat 4.1（或更高版本，大概），JSP的編譯由包含在Tomcat裏面的Ant程序控制器直接執行。這聽起來有一點點奇怪，但這正是Ant有意爲之的一部分，有一個API文檔指導開發者在沒有啓動一個新的JVM的狀況下，使用Ant。這是使用Ant進行Java開發的一大優點。另外，這也意味着你如今可以在Ant中使用任何javac支持的編譯方式，這裏有一個關於Apache Ant使用手冊的javac page列表。使用起來是容易的，由於你只須要在<init-param> 元素中定義一個名字叫「compiler」，而且在value中有一個支持編譯的編譯器名字，示例以下：

　　<servlet-name>jsp</servlet-name>

　　<servlet-class>

　　org.apache.jasper.servlet.JspServlet

　　</servlet-class>

　　<init-param>

　　<param-name>logVerbosityLevel</param-name>

　　<param-value>WARNING</param-value>

　　</init-param>

　　<init-param>

　　<param-name>compiler</param-name>

　　<param-value>jikes</param-value>

　　</init-param>