tomcat详解及其配置

　Tomcat 服务器是一个免费的开放源代码的Web 应用服务器，目前最新版本是6.0.20(截止到2009-10-22)。

　　Tomcat是Apache 软件基金会（Apache Software Foundation）的Jakarta 项目中的一个核心项目，由Apache、Sun 和其余一些公司及我的共同开发而成。因为有了Sun 的参与和支持，最新的Servlet 和JSP 规范老是能在Tomcat 中获得体现，Tomcat 5 支持最新的Servlet 2.4 和JSP 2.0 规范。由于Tomcat 技术先进、性能稳定，并且免费，于是深受Java 爱好者的喜好并获得了部分软件开发商的承认，成为目前比较流行的Web 应用服务器。

　　Tomcat 很受广大程序员的喜欢，由于它运行时占用的系统资源小，扩展性好，支持负载平衡与邮件服务等开发应用系统经常使用的功能；并且它还在不断的改进和完善中，任何一个感兴趣的程序员均可以更改它或在其中加入新的功能。

　　Tomcat 是一个小型的轻量级应用服务器，在中小型系统和并发访问用户不是不少的场合下被广泛使用，是开发和调试JSP 程序的首选。对于一个初学者来讲，能够这样认为，当在一台机器上配置好Apache 服务器，可利用它响应对HTML 页面的访问请求。实际上Tomcat 部分是Apache 服务器的扩展，但它是独立运行的，因此当你运行tomcat 时，它实际上做为一个与Apache 独立的进程单独运行的。

　　这里的诀窍是，当配置正确时，Apache 为HTML页面服务，而Tomcat 实际上运行JSP 页面和Servlet。另外，Tomcat和IIS、Apache等Web服务器同样，具备处理HTML页面的功能，另外它仍是一个Servlet和JSP容器，独立的Servlet容器是Tomcat的默认模式。不过，Tomcat处理静态HTML的能力不如Apache服务器。

Tomcat配置的10个技巧

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

　　大多数商业化的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 。

　　必须编辑这个文件，以肯定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 到该文件中，以下：

　　<role name=“admin”/>

　　一样须要有一个用户，而且这个用户的角色是“admin”。象存在的用户那样，添加一个用户（改变密码使其更加安全）：

　　<user name=“admin” password=“deep_dark_secret” roles=“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”的角色到该文件中：

　　<role name=“manager”>

　　一样须要有一个角色为“manager”的用户。像已经存在的用户那样，添加一个新用户（改变密码使其更加安全）：

　　<user name=“manager” password=“deep_dark_secret” roles=“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中添加几行内容，以下：

　　<Server port=“8005” shutdown=“SHUTDOWN” debug=“0”>

　　<Service name=“Tomcat-Standalone”>

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

　　<Engine name=“Standalone” defaultHost=“localhost” debug=“0”>

　　<!-- This Host is the default Host -->

　　<Host name=“localhost” debug=“0” appBase=“webapps”

　　unpackWARs=“true” autoDeploy=“true”>

　　<Context path=“” docBase=“ROOT” debug=“0”/>

　　<Context path=“/orders” docBase=“/home/ian/orders” debug=“0”

　　reloadable=“true” crossContext=“true”>

　　</Context>

　　</Host>

　　<!-- This Host is the first “Virtual Host”: www.example.com -->

　　<Host name=“www.example.com” appBase=“/home/example/webapp”>

　　<Context path=“” docBase=“.”/>

　　</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>

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

　　<load-on-startup>3</load-on-startup>

　　</servlet>

　　固然，给出的编译器必须已经安装在你的系统中，而且CLASSPATH可能须要设置，那处决于你选择的是何种编译器。

　　10.限制特定主机访问（Restricting Access to Specific Hosts）

　　有时，可能想限制对Tomcat web应用的访问，好比，但愿只有指定的主机或IP地址能够访问应用。这样一来，就只有那些指定的的客户端能够访问服务的内容了。为了实现这种效 果，Tomcat提供了两个参数供你配置：RemoteHostValve 和RemoteAddrValve。

　　经过配置这两个参数，可让你过滤来自请求的主机或IP地址，并容许或拒绝哪些主机/IP。与之相似的，在Apache的httpd文件里有对每一个目录的容许/拒绝指定。

　　能够把Admin Web application设置成只容许本地访问，设置以下：

　　<Context path=“/path/to/secret_files” …>

　　<Valve className=“org.apache.catalina.valves.RemoteAddrValve”

　　allow=“127.0.0.1” deny=“”/>

　　</Context>

　　若是没有给出容许主机的指定，那么与拒绝主机匹配的主机就会被拒绝，除此以外的都是容许的。与之相似，若是没有给出拒绝主机的指定，那么与容许主机匹配的主机就会被容许，除此以外的都是拒绝的。