Tomcat服务器配置参考

Tomcat服务器配置参考 DefaultContext组件

Introduction

DefaultContext元素代表Context元素的配置设置的一个子集，可以嵌套在Engine或者Host元素中，表示自动创建的Context的缺省配置属性。 在什么情况下，Catalina会自动创建Context？有关这方面的更多信息，参考应用自动发布和用户web应用。

属性

公共属性 所有DefaultContext的实现支持如下属性： 属性 描述 cookies 如果想利用cookies来传递session identifier（需要客户端支持cookies），设为ture。否则为false，这种情况下只能依靠URL Rewriting传递session identifier。 crossContext 如果想在应用内调用ServletContext.getContext()来返回在该虚拟主机上运行的其他web application的request dispatcher,设为true。在安全性很重要的环境中，设为false，使得getContext()总是返回null。缺省值为false。 reloadable 如果希望Catalina监视/WEB-INF/classes/和/WEB-INF/lib下面的类是否发生变化，在发生变化的时候自动重载web application，设为true。这个特征在开发阶段很有用，但也大大增加了服务器的开销。因此，在发布以后，不推荐使用。但是，你可以使用Manager应用在必要的时候触发应用的重载。 wrapperClass org.apache.catalina.Wrapper实现类的名称，用于该Context管理的servlets。如果没有指定，使用标准的缺省值。 标准实现 DefaultContext的标准实现是org.apache.catalina.core.DefaultContext，它还支持如下的附加属性： 属性 描述 swallowOutput 如果该值为true，System.out和System.err的输出被重定向到web应用的logger。如果没有指定，缺省值为false useNaming 如果希望Catalina为该web应用使能一个JNDI InitialContext对象，设为true。该InitialialContext符合J2EE平台的约定，缺省值为true。

嵌套组件

专有特征

Contxt参数（Context Parameters） 可以在Context中元素中嵌套<Parameter>元素，配置带有名称的值，这些值作为servletcontext初始化参数，对整个web应用可见。比如，你可以像这样创建初始化参数: <DefaultContext ...> ... <Parameter name="companyName" value="My Company, Incorporated" override="false"/> ...</DefaultContext> 这与在/WEB-INF/web.xml中包含如下元素相等： <context-param> <param-name>companyName</param-name> <param-value>My Company, Incorporated</param-value></context-param> 区别是，前者不需要修改deployment descriptor来定制这个值。 <Parameter>元素的有效属性值如下： 属性 描述 description 关于该context初始化参数的文字描述（可选） name 要创建的context初始化参数的名称 override 如果不希望/WEB-INF/web.xml中具有相同参数名称的<context-param>覆盖这里指定的值，设为false。缺省值为true。 value 调用ServletContext.getInitParameter()时，返回给应用的参数值。 环境条目 可以在Context中嵌套<Environment>元素，配置命名的值，这些值作为环境条目资源(Environment Entry Resource），对整个web应用可见。比如，可以按照如下方法创建一个环境条目： <DefaultContext ...> ... <Environment name="maxExemptions" value="10" type="java.lang.Integer" override="false"/> ...</DefaultContext> 这与在/WEB-INF/web.xml中包含如下元素是等价的： <env-entry> <env-entry-name>maxExemptions</param-name> <env-entry-value>10</env-entry-value> <env-entry-type>java.lang.Integer</env-entry-type></env-entry> but does not require modification of the deployment descriptor to customize 区别是，前者不需要修改deployment descriptor来定制这个值。 <Environment>元素的有效属性所如下： 属性 描述 description 环境条目的文字描述（可选） name 环境条目的名称，相对于java:comp/env context。 override 如果不希望/WEB-INF/web.xml中具有相同名称的<env-entry>覆盖这里指定的值，设为false。缺省值为true。 type 环境条目的Java类名的全称.在/WEB-INF/web.xml中，<env-entry-type>必须是如下的值：java.lang.Boolean, java.lang.Byte, java.lang.Character, java.lang.Double, java.lang.Float, java.lang.Integer, java.lang.Long, java.lang.Short, or java.lang.String. value 通过JNDI context请求时，返回给应用的参数值。这个值必须转换成type属性定义的Java类型 生命期Listeners（Lifecycle Listeners） 如果一个Java对象需要知道Context什么时候启动，什么时候停止，可以在这个对象中嵌套一个Listener元素。该Listener元素必须实现了org.apache.catalina.LifecycleListener接口，在发生对应的生命期事件的时候，通知该Listener。可以按照如下的格式配置这样的Listener： <DefaultContext ...> ... <Listener className="com.mycompany.mypackage.MyListener" ... > ...</DefaultContext> 注意，一个listener可以具有任意多的附加属性。属性名与JavaBean的属性名相对应，使用标准的属性命名方法。 资源定义（Resource Definitions） 可以在/WEB-INF/web.xml中定义资源的特性。使用JNDI查找<resource-ref>和<resource-env-ref>元素时，这些特性被返回。对同一资源名称，还必须定义资源参数（见下面“资源参数”小节），这些参数用来配置对象工厂（object factory）以及对象工厂的属性。 比如，你可以按照如下方式创建资源定义： <DefaultContext ...> ... <Resource name="jdbc/EmployeeDB" auth="Container" type="javax.sql.DataSource" description="Employees Database for HR Applications"/> ...</DefaultContext> 这等价于在/WEB-INF/web.xml中包含如下元素： <resource-ref> <description>Employees Database for HR Applications</description> <res-ref-name>jdbc/EmployeeDB</res-ref-name> <res-ref-type>javax.sql.DataSource</res-ref-type> <res-auth>Container</res-auth></resource-ref> 区别是，前者不需要修改deployment descriptor来定制这个值。 <Resource>元素的有效属性如下： 属性 描述 auth 指定是web应用代码本身sign on到对应的resource mananger，还是由container代表web应用sign on到resource manager。该属性的值必须是Application或者Container。如果在web application deployment descriptor中使用<resource-ref>，这个属性是必需的，如果使用<resource-env-ref>，这个属性是可选的。 description 资源的文字描述（可选） name 资源的名称，相对于java:comp/env context scope 指定通过这个resource manager得到的连接是否共享。该属性的值必须是Shareable或者Unshareable。缺省情况下，假定连接是共享的。 type 当web应用查找该资源的时候，返回的Java类名的全称。 资源参数（Resource Parameters） 资源参数用来配置资源管理器（resource manager，或对象工厂,object factory）。在做JNDI查找时，资源管理器返回查找的对象。在资源可以被访问之前，对<Context>或<DefaultContext>元素的每个<Resource>元素，或者/WEB-INF/web.xml中定义的每个<resource-ref>或<resource-env-ref>元素，都必须定义资源参数。 资源参数是用名称定义的，使用的资源管理器（或者object factory）不同，参数名称的集合也不一样。这些参数名和工厂类的JavaBeans属性相对应。JNDI实现通过调用对应的JavaBeans属性设置函数来配置特定的工厂类，然后通过lookup()调用使得该实例可见。 一个JDBC数据源的资源参数可以按照如下方式定义： <DefaultContext ...> ... <ResourceParams name="jdbc/EmployeeDB"> <parameter> <name>driverClassName</name> <value>org.hsql.jdbcDriver</value> </parameter> <parameter> <name>driverName</name> </value>jdbc:HypersonicSQL:database</value> </parameter> <parameter> <name>user</name> <value>dbusername</value> </parameter> <parameter> <name>password</name> <value>dbpassword</value> </parameter> </ResourceParams> ...</DefaultContext> 如果你需要为某个特定的资源类型指定工厂内的Java类名，在<ResourceParams>元素中嵌套一个叫做factory的<parameter>条目。 <Resourceparams>元素的有效属性如下： 属性 描述 name 配置的资源名称，相对于java:comp/env context。这个名称必须与$CATALINA_HOME/conf/server.xml中某个<Resource>元素定义的资源名称匹配，或者在/WEB-INF/web.xml中通过<resource-ref>或者<resource-env-ref>元素应用。 资源连接（Resource Links） 资源连接用于创建到全局JNDI资源的连接。在连接名称上进行JNDI查询会返回被连接的global 资源。 比如，你可以按照如下方法创建一个资源连接： <DefaultContext ...> ... <ResourceLink name="linkToGlobalResource" global="simpleValue" type="java.lang.Integer" ...</DefaultContext> <ResourceLink>元素的有效属性如下： 属性 描述 global 被连接的连接全局资源的名称 name 创建的资源连接的名称，相对于java:comp/env context type 当web应用在该资源连接上进行查找时，返回的Java类名的全称 GlobalNamingResources组件 概述 GlobalNamingResources定义了服务器的全局JNDI资源。 专有特征 环境条目 可以在GlobalNamingResources中嵌套<Environment>元素，配置命名的值，这些值作为环境条目资源(Environment Entry Resource），对整个web应用可见。比如，可以按照如下方法创建一个环境条目： <GlobalNamingResources ...> ... <Environment name="maxExemptions" value="10" type="java.lang.Integer" override="false"/> ...</GlobalNamingResources> 这与在/WEB-INF/web.xml中包含如下元素是等价的： <env-entry> <env-entry-name>maxExemptions</param-name> <env-entry-value>10</env-entry-value> <env-entry-type>java.lang.Integer</env-entry-type></env-entry> 区别是，前者不需要修改deployment descriptor来定制这个值。 <Environment>元素的有效属性所如下： 属性 描述 description 环境条目的文字描述（可选） name 环境条目的名称，相对于java:comp/env context。 override 如果不希望/WEB-INF/web.xml中具有相同名称的<env-entry>覆盖这里指定的值，设为false。缺省值为true。 type 环境条目的Java类名的全称.在/WEB-INF/web.xml中，<env-entry-type>必须是如下的值：java.lang.Boolean, java.lang.Byte, java.lang.Character, java.lang.Double, java.lang.Float, java.lang.Integer, java.lang.Long, java.lang.Short, or java.lang.String. value 通过JNDI context请求时，返回给应用的参数值。这个值必须转换成type属性定义的Java类型 （资源定义）Resource Definitions 可以在/WEB-INF/web.xml中定义资源的特性。使用JNDI查找<resource-ref>和<resource-env-ref>元素时，这些特性被返回。对同一资源名称，还必须定义资源参数（见下面“资源参数”小节），这些参数用来配置对象工厂（object factory）以及对象工厂的属性。 比如，你可以按照如下方式创建资源定义： <GlobalNamingResources ...> ... <Resource name="jdbc/EmployeeDB" auth="Container" type="javax.sql.DataSource" description="Employees Database for HR Applications"/> ...</GlobalNamingResources> 这等价于在/WEB-INF/web.xml中包含如下元素： <resource-ref> <description>Employees Database for HR Applications</description> <res-ref-name>jdbc/EmployeeDB</res-ref-name> <res-ref-type>javax.sql.DataSource</res-ref-type> <res-auth>Container</res-auth></resource-ref> 区别是，前者不需要修改deployment descriptor来定制这个值。 <Resource>元素的有效属性如下： Attribute Description auth 指定是web应用代码本身sign on到对应的resource mananger，还是由container代表web应用sign on到resource manager。该属性的值必须是Application或者Container。如果在web application deployment descriptor中使用<resource-ref>，这个属性是必需的，如果使用<resource-env-ref>，这个属性是可选的。 description 资源的文字描述（可选） name 资源的名称，相对于java:comp/env context scope 指定通过这个resource manager得到的连接是否共享。该属性的值必须是Shareable或者Unshareable。缺省情况下，假定连接是共享的。 type 当web应用查找该资源的时候，返回的Java类名的全称。 资源参数（Resource Parameters） 资源参数用来配置资源管理器（resource manager，或对象工厂,object factory）。在做JNDI查找时，资源管理器返回查找的对象。在资源可以被访问之前，对<Context>或<DefaultContext>元素的每个<Resource>元素，或者/WEB-INF/web.xml中定义的每个<resource-ref>或<resource-env-ref>元素，都必须定义资源参数。 资源参数是用名称定义的，使用的资源管理器（或者object factory）不同，参数名称的集合也不一样。这些参数名和工厂类的JavaBeans属性相对应。JNDI实现通过调用对应的JavaBeans属性设置函数来配置特定的工厂类，然后通过lookup()调用使得该实例可见。 一个JDBC数据源的资源参数可以按照如下方式定义： <GlobalNamingResources ...> ... <ResourceParams name="jdbc/EmployeeDB"> <parameter> <name>driverClassName</name> <value>org.hsql.jdbcDriver</value> </parameter> <parameter> <name>driverName</name> </value>jdbc:HypersonicSQL:database</value> </parameter> <parameter> <name>user</name> <value>dbusername</value> </parameter> <parameter> <name>password</name> <value>dbpassword</value> </parameter> </ResourceParams> ...</GlobalNamingResources> 如果你需要为某个特定的资源类型指定工厂内的Java类名，在<ResourceParams>元素中嵌套一个叫做factory的<parameter>条目。 <Resourceparams>元素的有效属性如下： 属性 描述 name 配置的资源名称，相对于java:comp/env context。这个名称必须与$CATALINA_HOME/conf/server.xml中某个<Resource>元素定义的资源名称匹配，或者在/WEB-INF/web.xml中通过<resource-ref>或者<resource-env-ref>元素应用。 Loader组件 概述 loader元素代表用来加载Java类和资源的类加载器。类加载器必须满足Servlet Specification规定的要求，它从以下位置加载类： web应用的/WEB-INF/classes目录； web应用的/WEB-INF/lib目录下的JAR文件； 由Catalina定义的对所有web应用都可用的资源； Loader可以嵌入Context组件中。如果没有包含该组件，会自动生成一个缺省的loader配置，这可以满足大多数需求。 如果想得到Catalina实现的类加载器层次结构的更深的描述，参考FIXME。 以下的描述使用变量$CATALINA_HOME来指Tomcat 5安装的目录。大多数的相对路径都是以该目录为基准。但是，通过设置CATALINA_BASE目录，可以运行多个Tomcat 5实例，这时你应该使用$CATALINA_BASE来作为目录基准，而不是使用$CATALINA_HOME。   属性 公共属性 所有Loader的实现支持如下属性： 属性 描述 className 实现的Java类名。这个类必须实现org.apache.catalina.Loader接口。如果没有指定，使用标准实现。 delegate 如果希望class loader遵从Java 2 delegation模型，在加载web应用的类之前，首先加载父亲class loader的类，设为true。缺省值为false，首先加载web应用的类，然后才要求其父亲class loader查找请求的类或者资源。 reloadable   如果希望Catalina监视/WEB-INF/classes/和/WEB-INF/lib下面的类是否发生变化，在发生变化的时候自动重载web application，设为true。这个特征在开发阶段很有用，但也大大增加了服务器的开销。因此，在发布以后，不推荐使用。但是，你可以使用Manager应用在需要的是否触发应用的重载。 注意：这个属性从Loader所属的Context元素的reloadable属性继承。这里设置的任何值都会被替换。 标准实现 Loader的标准实现是org.apache.catalina.loader.WebappLoader。它还支持如下的附件属性： 属性 描述 checkInterval 如果reloadable为true，检查类和资源是否被修改的时间间隔。缺省值为15秒。   debug 与这个Engine相关联的Logger的输出信息的详细程度。数字越大，输出越详细。如果没有指定，缺省值为0。   loaderClass 实现java.lang.ClassLoader的Java类名。如果没有指定，缺省值为org.apache.catalina.loader.WebappClassLoader   嵌套组件 Loader元素中不允许嵌套任何组件   专有特征 Loader元素没有任何专有特征 Logger组件 概述 Catalina容器（Engine，Host或者Context）使用Logger来记录日志信息，调试信息以及错误信息。另外，Engine和Host的Logger自动被低层的容器继承，除非被明确覆盖。 如果希望产生像web server一样的访问日志（比如，用于点击率分析软件），需要在Engine，Host或者Context元素中配置一个Access Log Valve。 想得到Catalina实现的class loader层次结构的更多信息，参考FIXME-Reference。 以下的描述使用变量$CATALINA_HOME来指Tomcat 5安装的目录。大多数的相对路径都是以该目录为基准。但是，通过设置CATALINA_BASE目录，可以运行多个Tomcat 5实例，这时你应该使用$CATALINA_BASE来作为目录基准，而不是使用$CATALINA_HOME。 属性 公共属性 所有的Logger实现支持如下属性： 属性 描述 className 实现的Java类名。该类必须实现org.apache.catalina.Logger接口   verbosity Logger记录信息的详细程度。如果要求记录的消息的级别比指定值要高，该消息被简单的忽略。可选的级别是0（只记录致命消息），1（错误），2（警告），3（信息），4（调试）。如果没有指定，缺省值为1，即只记录错误信息。 注意－只有在消息明确指定了级别的情况下，才和这个值进行比较。没有指定级别的消息被无条件记录下来。 标准实现 和大多数Catalina组件不一样的是，Logger有几个标准的实现。所以，必须使用className属性来指明你希望使用的实现。 File Logger (org.apache.catalina.logger.FileLogger) File Logger将所有的消息记录在指定目录下的磁盘文件中。日志文件的实际名称由前缀、当前日期（以YYYY-MM-DD格式）和后缀组成。对每天午夜以后的第一条日志消息，关闭当前的日志文件，为新的日期创建一个新的日志文件。日志文件的切换不需要关闭Catalina。 File Logger支持如下属性： 属性 描述 directory 存放日志文件的目录，可以是相对路径或者绝对路径。如果使用相对路径，是指相对于 $CATALINA_HOME的路径。如果不指定directory属性，缺省值是“logs”（相对于 $CATALINA_HOME） prefix 日志文件名的前缀。如果没有指定，缺省值是“catalina”。如果不想使用前缀，使用长度为0的字符串。 suffix 日志文件名称的后缀。如果没有指定，缺省值为“.log”。如果不想使用后缀，使用长度为0的字符串。 timestamp 如果为true，所有消息都会加上日期和时间戳。缺省值为false。 Standard Error Logger (org.apache.catalina.logger.SystemErrLogger) Standard Error Logger将所有的消息记录到Catalina使用的的标准错误输出上。缺省情况下，catalina使用相对于 $CATALINA_HOME的logs/catalina.out作为标准错误输出。该logger没有附件的属性。   Standard Output Logger (org.apache.catalina.logger.SystemOutLogger) Standard Outpout Logger将所有的消息记录到catalina使用的标准输出上。缺省情况下，catalina使用相对于 $CATALINA_HOME的logs/catalina.out作为标准输出。这个logger不支持附加属性。   嵌套组件 Loggr元素中不允许嵌套任何组件 专有特征 Logger元素没有任何专有特征 Manager组件 概述 Manger元素代表用来产生，维护HTTP session的session manager。 Manager元素可以嵌套在Context组件中。如果不包含它，会自动创建一个缺省的Manager配置，这对大多数需求都是足够的。 属性 公共属性 所有Manager的实现支持如下属性： 属性 描述 className 实现的Java类名。这个类必须实现org.apache.catalina.Manager接口。如果没有指定，使用标准值。 distributable 在分布式应用中，如果想加上Servlet Specification中描述的限制，设为true。这意味着所有的session属性必须实现java.io.Serializable接口。如果不想加上这些限制，设为false 注意：根据/web-inf/web.xml中是否存在<distributable>元素，这个属性值自动继承； 标准实现 Tomcat为Manger提供了两个标准实现。缺省的实现存储活动的session，可选的实现存储被交换出来的活动session（另外还存储tomcat重启前后的session)，存储的位置由嵌套的Store元素定义。 标准的Manager实现 Manger的标准实现是org.apache.catalina.session.StandardManger。它支持如下的附加属性： 属性 描述 algorithm 用于计算session标识符的消息摘要算法。这个值必须被java.security.MessageDigest类支持。如果没有指定，缺省值是“MD5” checkInterval 检查session是否过期的时间间隔，以秒为单位，缺省值是60秒 debug 与Manager相关的Logger记录的调试信息的详细程度，数字越大，输出越详细。如果没有指定，缺省值为0。 entropy 在创建session标识符中随机数发生器的种子。为字符串值。如果没有指定，计算一个不完全有用的值。在安全要求很高的环境中，应该指定一个长的字符串。 maxActiveSessions 产生的最大活动session数。如果为－1，说明没有限制。 pathname 如果可能的话，当应用重启时，用于保存session状态的文件的绝对或者相对路径。缺省为“SESSIONS.ser”。参考Restart Persistence，以得到更多信息 randomClass 实现java.util.Random的Java类名。如果没有指定，缺省为java.security.SecureRandom Persisten Manager实现 警告－这个实现还没有经过细致的测试，只能用于实验用途。 Manger的persistent实现是org.apache.catalina.session.PersistentManager。除了通常的创建和删除session以外，PersistentManger还能够将空闲的活动session交换到永久的存贮介质上面。当tomcat正常重启时，还可以将session保存下来。实际使用的存储机制由嵌套的store元素定义。使用PersistentManager时，store元素必须定义。 Manager的这个实现支持如下的附加属性: 属性 描述 algorithm 产生session identifier的消息摘要算法的名称。这个值必须被java.security.MessageDigest类支持。如果没有指定，缺省值为“MD5”。 checkInterval 检查session是否过期的时间间隔，以秒为单位，缺省值为60秒。 className 实现的Java类名。这个类必须实现 org.apache.catalina.Manager接口。对于persistent manager实现，必须指定为org.apache.catalina.session.PersistentManager。 debug 与Manager相关联的Logger记录信息的详细程度。数字越大，输出越详细。如果不指定，缺省值为0。 entropy 在创建session标识符中随机数发生器的种子。为字符串值。如果没有指定，计算一个不完全有用的值。在安全要求很高的环境中，应该指定一个长的字符串。 maxActiveSessions 产生的最大活动session数。如果为－1，说明没有限制。 maxIdleBackup 自上次访问某个session到这个session可以被保存到存储介质上的时间间隔。以秒为单位，如果为－1，则disable这个特征。缺省情况下，这个特征是disable的。 maxIdleSwap 自上次访问某个session到session应该被保存到存储介质上，并从服务器的内存中交换出来之间的时间间隔。如果为－1，则disable这个特征。如果使能了这个特征，指定值应该大于或者等于maxIdleBackup。缺省情况下这个特征是disable的。 minIdleSwap 自上次访问某个session到session可以被保存到存储介质上，并从服务器的内存中交换出来之间的时间间隔。如果为-1，说明可以在任何时间交换出来。指定值应该小于maxIdleSwap。缺省情况下这个特征是disable的。 randomClass 实现java.util.Random的Java类名。如果没有指定，缺省为java.security.SecureRandom saveOnRestart 当Tomcat关闭的时候，是否应该保存所有的session？Tomcat重启（或者应用重新载入）后是否应该恢复所有的session。缺省情况下为true。 为了成功使用PersistentManager，你必须嵌套一个<Store>元素，如下所述。 嵌套元素 标准Manager实现 如果使用Standard Manager实现，<Manager>元素中不需要嵌套任何元素 Persistent Manager实现 如果使用Persistent Manager实现，你必须在<Manager>元素中嵌套一个<Store>元素。<Store> 元素定义了数据存储的特性。目前<Store>元素有两个实现，下面描述了它们的特征。 基于文件的存储 基于文件的存储实现将交换出来的session存储在指定目录下的单个的文件中（根据session identifier命名）。因此，当活动session数目增加时，可能会碰到扩展性的问题，这种方法应该主要用在实验系统中。 为了配置基于文件的存储，在<Manager>元素中嵌套一个<store>元素，并具有如下属性： 属性 描述 checkInterval 检查当前被交换出来的session是否过期的时间间隔，缺省值为60秒。 className 实现的Java类名。这个类必须实现org.apache.catalina.Store接口。使用基于文件的存储时，必须将这个属性指定为org.apache.catalina.session.FileStore. debug 与Store元素相关联的Logger的调试信息的详细程度。数字越大，输出越详细。如果没有指定，缺省值为0。 directory 用来存储单个session文件的目录，可以是绝对或者相对路径（相对于这个web应用的临时工作目录）。如果没有指定，使用container指定的临时工作目录。   基于JDBC的存储 基于JDBC的存储实现将交换出来的session存储在预先配置好的数据库表中，每一行存储一个session。如果有大量的session需要交换出来，这种实现比基于文件的存储性能要好。 为了使用基于JDBC的存储，在<Manager>元素中嵌套一个<Store>元素，并配置如下属性： 属性 描述 checkInterval 检查当前被交换出来的session是否过期的时间间隔，缺省值为60秒。 className 实现的Java类名。该类必须实现org.apache.catalina.Stroe接口。为了使用基于JDBC的存储，这个指必须指定为org.apache.catalina.session.JDBCStore. connectionURL 建立数据库连接的URL，传递给JDBC驱动。 debug 与Store元素相关联的Logger的调试信息的详细程度。数字越大，输出越详细。如果没有指定，缺省值为0。 driverName 使用的JDBC驱动的Java类名 sessionAppCol session表中的数据库列名，包含Engine，Host和Web应用上下文的名称，格式为/Engine/Host/Context sessionDataCol session表中的数据库列名，包含交换出来的session的所有属性序列化以后的形式。列类型必须能够接受二进制对象（称作BLOB） sessionIdCol Session表中的数据库列名，包含交换出来的session的session标识符。该列必须接受字符串数据，并且至少要能装下session标识符的所有字符（通常为32） sessionLastAccessedCol session表中的数据库列名，包含session的lastAccessedTime属性。该列必须接受Java长整型数据（64bits） sessionMaxInactiveCol session表中的数据库列名，包含session的maxInactiveInterval属性。该列必须接受Java整型数据（32bits） sessionTable 用来存储交换出来的session的表名。这个表至少必须包含上面列出的列。   sessionValidCol session表中的列名，包含一个标志，表名交换出来的session是否有效。该列必须接受单个字符。 在第一次使用基于JDBC的存储之前，必须创建用来存储session的表。具体的SQL命令取决于你使用的数据库，但一般来说，具有象下面的格式： create table tomcat_sessions ( session_id varchar(100) not null primary key, valid_session char(1) not null, max_inactive int not null, last_access bigint not null, app_name varchar(255), session_data mediumblob, KEY kapp_name(app_name)); 为了使基于JDBC的存储成功地连接到你的数据库，JDBC驱动对Tomcat的内置class loader必须是可见的。一般来说，这意味着你必须把包含驱动的JAR文件放在$CATALINA_HOME/server/lib下面（如果你的应用不需要使用JDBC驱动）或者放在$CATALINA_HOME/common/lib目录下面（如果希望将驱动和web应用共享） 专有特征 Restart Persistence 每当Catalina被正常关闭后重新启动，或者应用被重新载入，标准的Manager实现会尝试将目前所有的活动session序列化到一个磁盘文件中，通过pathname属性。当应用完成重载以后，所有存储的session被deserialized，激活（假定session同时还没有过期）； 为了成功恢复session属性的状态，所有的属性必须实现java.io.Serializable接口。通过在/WEB-INF/web.xml中包含<distributable>元素，可以要求Manager加上这个限制。 Realm组件 概述 Realm元素是一个包含用户名，密码和用户角色的数据库。角色与Unix的group类似。Realm的不同实现允许将Catalina集成到认证信息已经被创建和维护的环境中，然后利用这些信息来实现Container Managed Security，如Servlet Specification中所述。 你可以在任何Catalina容器（Engine，Host或者Context）中嵌套Realm元素。另外，Engine或者Host的Realm会自动被低层次的容器继承，除非被明确覆盖。 有关web应用中container managed security的更多信息，参考FIXME-应用开发者这一部分中“Container Managed Security指南”的连接；有关配置和使用标准Realm实现的更多信息，参考FIXME-管理者这一部分中的"Realm Configuration HOW-TO"连接。 以下的描述使用变量$CATALINA_HOME来指Tomcat 5安装的目录。大多数的相对路径都是以该目录为基准。但是，通过设置CATALINA_BASE目录，可以运行多个Tomcat 5实例，这时你应该使用$CATALINA_BASE来作为目录基准，而不是使用$CATALINA_HOME。 属性 公共属性 所有Realm的实现支持如下属性： 属性 描述 className 实现的Java类名。这个类必须实现org.apache.catalina.Realm接口。 标准实现 和大多数Catalina组件不一样的是，Realm有几个标准的实现。所以，必须使用className属性来选择你希望使用的实现。 JDBC Database Realm (org.apache.catalina.realm.JDBCRealm) JDBC Database Realm将Catalina连接到一个关系数据库，通过正确的JDBC驱动访问,用来查询用户名，密码和他们相关的角色。由于查询是在每次必要的时候完成的，因此数据库的改变会马上反映到用来认证新登录的信息中。 除了用来获取必需信息的数据库表名和列名以外，还有很多附加的属性用来配置到数据库的连接： 属性 描述 connectionName 建立JDBC连接时使用的数据库用户名 connectionPassword 建立JDBC连接时使用的数据库密码 connectionURL 建立数据库连接时传递给JDBC驱动的连接URL digest 用来对数据库中的用户密码编码的“消息摘要”算法的名称。如果没有指定，密码以明文方式存储。 driverName 连接到认证数据库的JDBC驱动的完整的Java类名 roleNameCol “用户角色“表中的列名，包含了指定给对应用户的角色名称。 userCredCol “用户”表中的列名，包含用户的可信数据（比如，密码）。如果设置了digest属性，则假定密码已经用了指定的算法进行编码，否则，假定密码是明文密码。 userNameCol “用户”表和“用户角色”表中的列名，包含用户的用户名 userRoleTable “用户角色”表名，必须包含userNameCol和roleNameCol指定的列。 userTable 用户表，必须包含userNameCol和userCredCol属性指定的列 有关使用JDBC Database Realm组件来设置container managed security的更多信息，参考FIXME - Nested pointer into HOW-TO DataSource Database Realm (org.apache.catalina.realm.DataSourceRealm) DataSource Database Realm 将Catalina连接到一个关系数据库，通过一个名为JDBC Datasource的JNDI访问，查询用户名，密码以及他们对应的角色。由于查询在每次需要的时候进行，因此数据库的变化会马上反映到用来认证新的登录的信息上。 JDBC Realm使用单个数据库连接。这要求基于realm的认证之间同步，比如，同一时刻只允许一个认证。这对需要大量使用认证的应用程序来说是一个瓶颈。 DataSource Database Realm支持并发的基于Realm的认证，允许JDBC DataSource处理优化问题，比如数据库连接池。 有很多选项可以配置JNDI JDBC Datasource的名字，同时包括用来获取必要信息的数据库表名和列名。 属性 描述 dataSourceName Realm的JNDI JDBC DataSource的名字 digest 用来对存储在数据库中的用户密码编码的消息摘要算法的名称。如果没有指定，假定用户密码以明文方式存储。 roleNameCol “用户角色“表中的列名，包含了指定给对应用户的角色名称。 userCredCol “用户”表中的列名，包含了用户的可信数据（比如，密码）。如果设置了digest属性，则假定密码已经用了指定的算法进行编码，否则，假定密码是明文密码。 userNameCol “用户”表和“用户角色”表中的列名，包含用户的用户名。 userRoleTable 用户角色表名，必须包含userNameCol和roleNameCol指定的列。 userTable 用户表，必须包含userNameCol和userCredCol属性指定的列。 有关使用DataSource Database Realm组件配置container managed security的更多信息，参考DataSource Realm HOW-TO。 JNDI Directory Realm (org.apache.catalina.realm.JNDIRealm) JNDI Directory Realm将Catalina连接到一个LDAP目录，通过正确的JNDI驱动访问。LDAP目录存储了用户名，密码以及他们相应的角色。对目录的修改马上反映到用来认证新的登录的数据上面。 directory realm支持许多使用LDAP进行认证的方法： realm可以使用模式来决定用户目录条目的唯一名字（distinguished name），或者搜索目录来定位该条目； realm可以将用户条目的唯一名字和用户给出的密码绑定到目录上，对用户进行认证；或者，从用户条目中取出密码，在本地进行比较； 在目录中,角色可以以单独的条目存在（比如，用户所属的组条目），或者，角色可以是用户条目的一个属性，或者两种情况都是； 除了到目录的连接，用户从目录中获取信息的元素和属性名称以外，Directory Realm还支持很多其他的附加属性： 属性 描述 authentication 使用的认证类型，字符串类型。可以是“none”，“simple”，“strong”或者提供者定义的其他类型，如果没有值，使用提供者提供的缺省值。 connectionName 创建目录连接使用的目录用户名。如果没有指定，使用匿名连接，这在大多数情况下就足够了，除非你指定了userPassword属性 connectionPassword 创建目录连接使用的目录密码。如果没有指定，使用匿名连接，这在大多数情况下就足够了，除非你指定userPassword属性。 connectionURL 创建目录连接时，传递给JNDI驱动的连接URL。 contextFactory 用来取得JNDI InitialContext的工厂类的Java类名。缺省情况下，假定使用标准的JNDI LDAP提供者。 protocol 使用的安全协议。如果没有指定，使用提供者提供的缺省值。 roleBase 用于角色查找的基准目录条目。如果没有指定，使用目录上下文的*元素。 roleName 在角色查找中，包含角色名的属性的名称。另外，在用户条目中，你可以使用userRoleName来指定包含额外角色名的属性名称，。如果没有指定，不搜索角色，角色存在于用户条目中。 roleSearch 用来进行角色查找的LDAP过滤器表达式。使用{0}来代替用户的唯一名称，{1}来代替用户名。如果没有指定，不对角色进行搜索，角色从用户条目中由userRoleName指定的属性得到。 roleSubtree 在查找与用户相关联的角色时，如果想搜索由roleBase属性指定的元素的整个子树，设为true。缺省值为false，只对*元素进行搜索。 userBase 在使用userSearch表达式搜索用户的时候的基准元素。如果使用userPattern表达式进行搜索，不使用这个属性。 userPassword 在用户条目中包含用户密码的属性名。如果指定了这个值，JNDIRealm使用connectionName和connectionPassword属性指定的值绑定到目录，取出对应的属性，与被认证的用户给出的值进行比较。如果不指定这个值，JNDIRealm会尝试使用用户条目的唯一名称和用户给出的密码绑定到目录，如果绑定成功，说明认证成功。 userPattern 用户目录条目的唯一名称的模式，{0}代表实际的用户名。在唯一名称包含用户名，其他的项都相同的时候，可以使用这个属性，而不是使用userSearch，userSubtree和userBase. userRoleName 用户目录条目中的一个属性名，该属性包含了零个或多个指定给用户的角色名的值。另外，如果角色以单独的条目存在，可以使用roleName属性来指定属性名，在搜索目录的时候，可以得到这个属性。 如果不指定userRoleName，用户的所有角色通过角色搜索得到； userSearch 搜索用户目录条目时，使用的LDAP过滤表达式，{0}代表实际的用户名，可以使用userSearch，userBase和userSubtree属性一起来代替userPattern搜索目录。 userSubtree 如果希望搜索由userBase属性指定的元素的整个子树，设为true，缺省值为false，即只搜索*元素。如果使用userPattern表达式，不使用这个属性。 有关使用JNDI Directory Realm组件设置container managed security的更多信息，参考 FIXME - Nested pointer into HOW-TO   Memory Based Realm (org.apache.catalina.realm.MemoryRealm) Memory Based Realm是一个简单的Realm实现，它从XML文件中读取用户信息，将这些信息标识为内存中的一系列Java对象的集合。这个实现只是用来启动container managed security，而不是用在产品中。所以，当数据文件改变的时候，没有机制来更新内存中用户的集合。 Memory Based Realm实现支持如下的附加属性： 属性 描述 pathname 包含用户信息的XML文件的绝对或者相对路径。XML文件的格式在下面定义。如果没有指定这个属性，缺省值为conf/tomcat-users.xml 由pathname属性引用的XML文档必须满足如下需求： 根元素必须是<tomcat-users> 每个授权用户必须用单个XML元素<user>来标识，嵌套在根元素中 每个<user>元素必须具有下列属性： name - 用户名(在文件内必须唯一). password - 用户密码(明文). roles - 用户角色列表，用逗号分开； 关于使用Memory Based Realm组件设置container managed security的更多信息，参考FIXME - Nested pointer into HOW-TO 嵌套元素 Realm元素中不能嵌套任何元素 专有特征 参考单次登录，以得到在虚拟主机上支持单次登录的更多信息   Resource组件 概述 Resources元素代表web应用的静态资源，这些资源用于类的加载，并服务于HTML，JSP和其他静态页面。这允许web应用位于除了文件系统的其他媒介中，比如压缩在一个WAR文件，JDBC数据库，或者更先进的版本仓库（versioning repository）中。 对webapp资源的所有访问，提供了一个统一的缓存引擎。资源可以被servlet container访问，web应用可以利用container提供的机制访问特定的资源，比如通过ServletContext接口访问class loader，通过DirectoryContext接口进行本地访问（Native Access）。 注意：如果某个webapp使用基于非文件系统的Resources实现，这只有在webapp不依赖对文件系统的直接访问来访问它自己的资源，而是使用ServletContext接口中提供的方法来访问它们。 Resources元素可以嵌在Context组件中。如果没有包含Resource，会生成一个缺省的基于文件系统的Resources，这对大多数需求都是足够的。   属性 公共属性 所有Resources的实现支持如下属性: 属性 描述 className 实现的Java类名。这个类必须实现javax.naming.directory.DirContext接口。考虑功能和性能上的优化，推荐该类继承org.apache.naming.resources.BaseDirContext。但这不是必须的。另外，推荐使用在org.apache.naming.resources提供的特殊的对象类型作为返回对象。如果没有指定，使用标准值。   标准实现 Resources的标准实现是org.apache.naming.resources.FileDirContext。它还支持如下的附加属性： 属性 描述 cached 资源是否需要缓存，缺省为true。   cacheMaxSize 如果cached为true，缓存的最大值，以KB为单位。缺省为10240（10M)   caseSensitive 在Windows平台上的资源是否区分大小写。缺省为真   docBase 等价于Context的文档基准目录（Document Base） 嵌套组件 Resource元素中不允许嵌套任何组件 专有特征 Resources元素没有任何专有特征。 Valve组件 概述 Valve元素是插入在Catalina容器（包括Engine,Host或者Context）处理流程中的组件。不同的组件有不同的处理能力。下面将对每个Valve组件进行描述 以下的描述使用变量 $CATALINA_HOME来指Tomcat 5安装的目录。大多数的相对路径都是以该目录为基准。但是，通过设置CATALINA_BASE目录，可以运行多个Tomcat 5实例，这时你应该使用$CATALINA_BASE来作为目录基准，而不是使用$CATALINA_HOME。 访问日志Valve 概述 Access Log Valve用来创建日志文件，格式与标准的web server日志文件相同。可以使用用日志分析工具对日志进行分析，跟踪页面点击次数、用户会话的活动等。Access Log Valve的很多配置和行为特性与File Logger相同，包括每晚午夜自动切换日志文件。Access Log Valve可以和任何Catalina容器关联，记录该容器处理的所有请求。 属性 Access Log Valve支持如下配置属性： 属性 描述 className 实现的Java类名。必须被设置成org.apache.catalina.valves.AccessLogValve。 directory 存放日志文件的目录，可以是相对路径或者绝对路径。如果使用相对路径，是指相对于 $CATALINA_HOME的路径。如果不指定directory属性，缺省值是“logs”（相对于 $CATALINA_HOME） pattern 需要记录的请求/响应不同信息域的格式布局。如果是“common”或者“combine”，说明选择标准格式。下面会有关于配置这个属性的更多信息。 prefix 日志文件名的前缀。如果没有指定，缺省值是“access_log.”。如果不想使用前缀，使用长度为0的字符串。   resolveHosts 将远端主机的IP地址通过DNS查询转换成主机名，设为true。如果为false，忽略DNS查询，报告远端的IP地址。   suffix 日志文件名的后缀。如果没有指定，缺省值是“”。如果不想使用后缀，使用长度为0的字符串。   rotatable 缺省值为true，用来决定日志是否翻转的标志。如果为false，日志文件永远不翻转，并且忽略fileDataFormat。要谨慎使用。   condition 打开条件日志。如果设置了这个属性，只有在ServletRequest.getAttribute()是null的时候，才会为请求创建日志。比如，如果condition设为junk，则只有在Servlet.getAttribute("junk")==null的时候，才会记录这个请求。使用过滤器，可以很容易设置（或者取消设置）不同请求的属性。 fileDateFormat 允许在日志文件名称中使用定制的日期格式。日志的格式也决定了日志文件翻转的频率。如果想每个小时翻转一次，将这个值设为yyyy-MM-dd.HH pattern属性值由字符串常量和pattern标识符加上前缀"%"组合而成。pattern标识符加上前缀"%"，用来代替当前请求/响应中的对应的变量值。目前支持如下的pattern： %a - 远端IP地址 %A - 本地IP地址 %b - 发送的字节数，不包括HTTP头，如果为0，使用"－" %B - 发送的字节数，不包括HTTP头 %h - 远端主机名(如果resolveHost=false，远端的IP地址） %H - 请求协议 %l - 从identd返回的远端逻辑用户名（总是返回 '-'） %m - 请求的方法（GET，POST，等） %p - 收到请求的本地端口号 %q - 查询字符串(如果存在，以 '?'开始) %r - 请求的第一行，包含了请求的方法和URI %s - 响应的状态码 %S - 用户的session ID %t - 日志和时间，使用通常的Log格式 %u - 认证以后的远端用户（如果存在的话，否则为'-'） %U - 请求的URI路径 %v - 本地服务器的名称 %D - 处理请求的时间，以毫秒为单位 %T - 处理请求的时间，以秒为单位 Access Log Valve还可以记录cookie，消息头，Session或者ServletRequest中的信息。使用与apache类似的语法： %{xxx}i 消息头 %{xxx}c 特定的cookie %{xxx}r xxx 是ServletRequest中的某个属性 %{xxx}s xxx 是HttpSession中的某个属性 上面提到"common"模式（也是缺省的模式）实际上是"%h %l %u %t "%r" %s %b"的一种简单表示方法 "common"模式后面加上"Referer"和用户代理头(User-Agent headers)的信息，就是前面提到的"combined"模式。 远端地址过滤器(Remote Address Filter) 概述 远端地址过滤器将发起请求的客户端的IP地址和一个或多个正则表达式进行比较，以决定接受或者拒绝这个请求。远端地址过滤器可以嵌套在任何Catalina容器中（Engine，Host或者Contxt）。在过滤器起作用之前，容器必须接受所有的请求。 属性 远端地址过滤器支持如下的配置属性： 属性 描述 className 实现的Java类名，必须设置成org.apache.catalina.valves.RemoteAddrValve. allow 用逗号分开的一串正则表达式，客户端的IP地址与这些正则表达式进行比较。如果指定了这个属性，客户端的地址必须匹配这些表达式，其请求才会被处理。如果没有指定这个属性，所有的请求都被接受，除非客户端地址匹配了一个deny模式。 deny 用逗号分开的一串正则表达式，客户端的IP地址与这些正则表达式进行比较。如果指定了这个属性，客户端的地址一定不能匹配这些表达式，其请求才会被接受。如果没有指定这个属性，仅仅由"accept“属性决定是否接受这个请求。 远端主机过滤器（Remote Host Filter） 概述 远端主机过滤器将发起请求的客户端的主机名和一个或者多个正则表达式进行比较，以决定接受或者拒绝这个请求。远端主机过滤器可以嵌套在任何Catalina容器中（Engine，Host或者Context）。在过滤器起作用之前，容器必须接受所有的请求。 属性 远端主机过滤器支持如下属性： 属性 描述 className 实现的Java类名，必须设为org.apache.catalina.valves.RemoteHostValve. allow 用逗号分开的一串正则表达式，客户端的主机名与这些正则表达式进行比较。如果指定了这个属性，客户端的主机名必须匹配这些表达式，其请求才会被处理。如果没有指定这个属性，所有的请求都被接受，除非客户端主机名匹配了一个deny模式。 deny 用逗号分开的一串正则表达式，客户端的主机名与这些正则表达式进行比较。如果指定了这个属性，客户端的主机名一定不能匹配这些表达式，其请求才会被接受。如果没有指定这个属性，仅仅由"accept“属性决定是否接受这个请求。 Request Dumper Valve 概述 Request Dumper Valve在调试与客户端的交互非常有用。如果配置，它会利用容器（Engine，Host或者Context）的Logger记录下每个请求的详细信息。 属性 Request Dumper Valve支持如下配置属性： 属性 描述 className 实现的Java类名，必须设为org.apache.catalina.valves.RequestDumperValve. 单次登录Valve（Single Sign On Valve） 概述 如果希望用户可以登录到虚拟主机中的任意一个web应用，而且登录以后所有其他的web应用都能使用用户的身份信息（即不需要重新登录），就可以使用单次登录Valve。 在Host元素中有更多关于单次登录Valve的信息。 属性 单次登录Valve支持如下的配置属性： 属性 描述 className 实现的Java类名，必须设为：org.apache.catalina.authenticator.SingleSignOn. debug 这个组件的调试信息的详细程度，缺省值为0，即没有调试输出。