各种作用

web.xml是Tomcat的部署描述符文件，配置文件 指定路径用的

web.xml文件是用来配置：欢迎页、servlet、filter等的。当你的web工程没用到这些时，你可以不用web.xml文件来配置你的web工程
web.xml的模式文件中定义的标签并不是定死的，模式文件也是可以改变的，一般来说，随着web.mxl模式文件的版本升级，里面定义的功能会越来越复杂，也即标签元素的种类会越来越多，但有些是不常用的，我们只需记住一些常用的就可以了。
一个web中完全可以没有web.xml文件，也就是说，web.xml文件并不是web工程必须的。
web.xml
大家都知道，在Tomcat5及其以后的版本中，当启动tomcat之后，是看不到控制台中的manager应用的。Manager的应用还是很有好处的，可以直接在控制台上（类似于weblogic上的console应用）增加或者发布新的应用，重启，停掉，卸载当前应用。 
Tomcat5以及以后的版本，将所有的用户角色都关闭了，所以每次启动的时候是进不去 
Tomcat Manager的，那么怎么恢复这个呢？ 
下面以Tomcat-6.0.29版本为例： 
首先：找到你的Tomcat安装目录或者解压目录,例如：D:\work\apache-tomcat-6.0.29-windows-x86\apache-tomcat-6.0.29 
在这个目录下找到conf/tomcat-users.xml文件，打开 
看到<tomcat-users>和</tomcat-users>之间的所有内容是注释掉的， 
先去掉注释，如： 
  <role rolename="tomcat"/> 
  <role rolename="role1"/> 
  <user username="tomcat" password="tomcat" roles="tomcat,role1 "/> 
  <user username="both" password="tomcat" roles="tomcat,role1"/> 
  <user username="admin" password="admin" roles="tomcat,role1"/> 
  <user username="role1" password="tomcat" roles="role1"/> 


这个文件是指定控制台的用户，角色，密码的。 
然后会发现：这样恢复了之后还是不行，你会发现Tomcat Manager应用还是进不去。 
仔细看看最上面的注释， 
<!-- 
  NOTE:  By default, no user is included in the "manager" role required 
  to operate the "/manager" web application.  If you wish to use this app, 
  you must define such a user - the username and password are arbitrary. 
--> 


明白了吧，默认是没有manager角色的，那么我们可以修改上述配置文件，如下： 
  <role rolename="tomcat"/> 
  <role rolename="role1"/> 
  <user username="tomcat" password="tomcat" roles="tomcat,role1,manager"/> 
  <user username="both" password="tomcat" roles="tomcat,role1"/> 
  <user username="admin" password="admin" roles="tomcat,role1"/> 
  <user username="role1" password="tomcat" roles="role1"/> 


这样tomcat用户就具有访问manager的角色和权限了。 
然后启动tomcat,访问：http://localhost:8080/ 
点击左侧的：Tomcat Manager 
tomcat-users.xml
Tomcat是以面向对象的方式运作的；在执行期间，它会基于配置文件的设定动态地组建其对象结构。
   这有点像Apache httpd的“模块”，只是相对而言更复杂些。同时，这也类似于Unix的管道与过滤器。
   Server.xml文件中的每个主要元素都会创建软件“对象”、排序及进程管道中设置的这些元素嵌套方，让您能执行过滤、分组等工作。
   示例：Tomcat 6.0的简单server.xml文件
   <Server port="8005" shutdown="SHUTDOWN">
   <Listener className="org.apache.catalina.core.JasperListener"/>
   <Listener className="org.apache.catalina.mbeans.ServerLifecycleListener"/>
   <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"/>
      <GlobalNamingResources>
         <Resource name="UserDatabase" auth="Container"
            type="org.apache.catalina.UserDatabase"
            description="User database that can be updated and saved"
            factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
            pathname="conf/tomcat-users.xml"/>
      </GlobalNamingResources>
      <Service name="Catalina">
         <Connertor port="8080" protocol="HTTP/1.1"
            maxThreads="150" connectionTimeout="20000"
            redirectPort="8443"/>
         <Engine name="Catalina" defaultHost="localhost">
         <Host name="localhost" appBase="webapps"
            unpakWARs="ture" autoDeploy="true"
            xmlValidation="false" xmlNamespaceAware="false">
         </Host>
         </Engine>
      </Service>
   </Server>
   这是最简单的server.xml文件，但仍然能以兼容于存储的Tomcat server.xml文件的方式，服务于appBase目录(默认webapps/)下的所有Web应用程序而著称。
   但是，请记住，不推荐用类似于上面的简化的(stripped-down)server.xml文件运行Tomcat。笔者已经见过许多tomcat用户用最简单的server.xml运行Tomcat，最终导致其内容非常模糊，以至难以诊断问题的根源。
   笔者建议，只按web应用程序所需的方式修改已存储的server.xml文件，并按您需要的方式运行。建议这样处理的原因有以下几点。
   1、在您第一次决定要在server.xml文件中保留哪些内容时，Web应用程序会间接取决于您认为不需要的一些server.xml配置元素或特殊属性。
   在启动Tomcat并部署Web应用程序时，本应该都工作正常，但系统启动失败，并提供了一些日志信息，显示Tomcat故障或Web应用程序故障。在大部分时间里，正常工作的必要配置信息都已存储在server.xml文件中。
   2、在升级Tomcat的时候，无论是否是基于同一分支升级到一个新的版本，都可以更改元素的属性和值。如果形成最小的server.xml文件，则无法区分您的server.xml与新版本的server.xml之间的差别。
   即使是细微的变化也能导致Tomcat行为的很大差异。另外，偶尔修补一个bug，也需要同时修改Tomcat的代码与server.xml中的细微配置。
   如果升级并取得了新的JAR文件但没有对server.xml进行相应的修改，则bug仍然存在，但只存在于您的安装中。当您在邮件清单或IRC中咨询该bug的时候，人们将告诉您，他们不能重现您的问题，而这是因为他们使用了已存储的server.xml。
   3、在初始化设置Tomcat并最小化server.xml文件很长一段时间之后，您或者其他人重现了这一结果并做了一些修改。您已经忘记了该配置是如何工作的，或者首先是因为从来就不知道，但您需要知道对Web应用程序进行了哪些特殊配置。
   您无法简单地区分存储的server.xml，因为太难与您的server.xml文件区分开。可以用点时间阅读一下有关server.xml文件的所有信息，以理解定制的配置要完成什么，但耗时处理这一事情大概不是什么明智之举。
   相反，您可以采用注解已存储的server.xml文件，而且就使修改后的配置等同于最小配置的功能。
   然后，就可以区分存储的(未修改的)server.xml文件与您刚修改的文件有何差别。为什么不在最初的时候进行这样的处理呢？
   记住这一点，存储的server.xml文件包含了很多XML注释，主要是未经启用的描述及示例配置元素。
   这些内容无疑将是很方便的。有许多元素已被提前配置好并取消了注释，这些元素都是很常用的元素。
   在文件中保留这些元素以便简化取消注释与使用的过程，这一方法已经帮助了很多Tomcat用户，但也使很多用户苦恼，因为他们认为server.xml用注释搅乱了所需要的元素。
   确实如此，但因为笔者前面陈述的原因，还是要坚持这一劝告，生成并使用最小化的server.xml文件。
server.xml
元素名 属性 说明 server port 指定一个端口，这个端口负责监听关闭tomcat的请求 shutdown 指定向端口发送的命令字符 service name 指定service的名字 Connector(表示客户端和service之间的连接) port 指定服务器端要创建的端口号，并在这个端口监听来自客户端的请求 minProcessors 服务器启动时创建的处理请求的线程数 maxProcessors 最大可以创建的处理请求的线程数 enableLookups 如果为true，则可以通过调用request.getRemoteHost()进行DNS查询来得到远程客户端的实际主机名，若为false则不进行DNS查询，而是返回其ip地址 redirectPort 指定服务器正在处理http请求时收到了一个SSL传输请求后重定向的端口号 acceptCount 指定当所有可以使用的处理请求的线程数都被使用时，可以放到处理队列中的请求数，超过这个数的请求将不予处理 connectionTimeout 指定超时的时间数(以毫秒为单位) Engine(表示指定service中的请求处理机，接收和处理来自Connector的请求) defaultHost 指定缺省的处理请求的主机名，它至少与其中的一个host元素的name属性值是一样的 Context(表示一个web应用程序，通常为WAR文件，关于WAR的具体信息见servlet规范) docBase 应用程序的路径或者是WAR文件存放的路径 path 表示此web应用程序的url的前缀，这样请求的url为http://localhost:8080/path/**** reloadable 这个属性非常重要，如果为true，则tomcat会自动检测应用程序的/WEB-INF/lib 和/WEB-INF/classes目录的变化，自动装载新的应用程序，我们可以在不重起tomcat的情况下改变应用程序 host(表示一个虚拟主机) name 指定主机名 appBase 应用程序基本目录，即存放应用程序的目录 unpackWARs 如果为true，则tomcat会自动将WAR文件解压，否则不解压，直接从WAR文件中运行应用程序 Logger(表示日志，调试和错误信息) className 指定logger使用的类名，此类必须实现org.apache.catalina.Logger 接口 prefix 指定log文件的前缀 suffix 指定log文件的后缀 timestamp 如果为true，则log文件名中要加入时间，如下例:localhost_log.2001-10-04.txt Realm(表示存放用户名，密码及role的数据库) className 指定Realm使用的类名，此类必须实现org.apache.catalina.Realm接口 Valve(功能与Logger差不多，其prefix和suffix属性解释和Logger 中的一样) className 指定Valve使用的类名，如用org.apache.catalina.valves.AccessLogValve类可以记录应用程序的访问信息 directory 指定log文件存放的位置 pattern 有两个值，common方式记录远程主机名或ip地址，用户名，日期，第一行请求的字符串，HTTP响应代码，发送的字节数。combined方式比common方式记录的值更多
context.xml