Tomcat是以面向对象的方式运作的；在执行期间，它会基于配置文件的设定动态地组建其对象结构。
这有点像Apache httpd的“模块”，只是相对而言更复杂些。同时，这也类似于Unix的管道与过滤器。
Server.xml文件中的每个主要元素都会创建软件“对象”、排序及进程管道中设置的这些元素嵌套方，让您能执行过滤、分组等工作。
示例：Tomcat 6.0的简单server.xml文件
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"/>
maxThreads="150" connectionTimeout="20000"
redirectPort="8443"/>
unpakWARs="ture" autoDeploy="true"
xmlValidation="false" xmlNamespaceAware="false">
这是最简单的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文件。
