发布时间 : 星期日 文章测试环境手册更新完毕开始阅读
全局 JNDI 资源上下文中。这个上下文和每个 web 应用程序的 JNDI 上下文不同。在全局 JNDI 上下文中定义的资源在每个 web 应用程序的 JNDI 上下文中不可见，但是可以通过 Resource Links 来改变这种可见性。如果您要了解在 Tomcat 中如何使用 JNDI 资源可以查阅参考资料。
从前面给出的 体系结构图 中可以看出GlobalNamingResources右边有四个不同颜色的小方块，它们表示GlobalNamingResources所支持的四个不同的特性。相同颜色的小方块可能也会出现在其它的地方，这表示在那里也支持相同的或相似的特性。每种特性的具体描述可以在文中的Special Features中找到。 Realm
从前面给出的 体系结构图 中可以看出，Realm组件在Engine、Host和Context中都有支持。
Realm是一个\数据库\存储着用户名、密码和角色信息。通过自定义Realm可以将Catalina集成到其它的环境。Engine、Host和Context中的Realm可以被较低级别的容器继承，即Host继承Engine的Realm，Context继承Host的Realm，除非我们显示的禁止这种继承。 Realm支持className一个公共属性。Tomcat提供了多个实现： org.apache.catalina.realm.JDBCRealm org.apache.catalina.realm.DataSourceRealm org.apache.catalina.realm.JNDIRealm org.apache.catalina.realm.MemoryRealm
如果您要了解这些Realm的更多信息，可以查阅这里。
如果您要了解这些Realm的更多的设置信息，可以查阅参考资料。 Loader
从前面给出的 体系结构图 中可以看出，Loader组件只在Context中都有支持。 Loader是web应用程序的类装载器。必须有一个类装载器按照Servlet Specification的要求从如下的位置装载类：
从web应用程序的/WEB-INF/classes目录装载
从web应用程序的/WEB-INF/lib目录中的jar文件中装载 从Catalina中装载对于所有web应用可见的资源
Loader元素应该嵌入到Context元素中，如果没有设置那么会自动创建一个默认的Loader。如果想更深入的了解Catalina实现的Loader可以查阅参考资料。
Loader支持className、delegate和reloadable三个公共属性，而标准实现org.apache.catalina.loader.WebappLoader还可能支持一些扩展属性。详细的内容您可以
查阅这里。 Manager
从前面给出的 体系结构图 中可以看出，Manager组件只在Context中有支持。 Manager是session管理器(session manager)，负责session的创建和维护。
Manager元素应该嵌入到Context元素中，如果没有设置那么会自动创建一个默认的Manager。 Manager支持className和distributableorg.apache.catalina.session.StandardManager
两个公共属性，而标准实现
和
org.apache.catalina.session.PersistentManager还可能支持一些扩展属性。详细的内容您可以查阅这里。
Resources
从前面给出的 体系结构图 中可以看出，Resources组件只在Context中有支持。 Resources表示web应用程序的静态资源。这使得我们有可能实现non-filesystem based Resources。如果想更深入的了解可以查阅参考资料
Resources元素应该嵌入到Context元素中，如果没有设置那么会自动创建一个默认的基于文件系统的Resources。 Resources
支
持
className
一
个
公
共
属
性
，
而
标
准
实
现
org.apache.naming.resources.FileDirContext还可能支持一些扩展属性。详细的内容您可以查阅这里。
WatchedResource
从前面给出的 体系结构图 中可以看出，WatchedResource组件只在Context中都有支持。 WatchedResource用来告知Auto Deployer那些静态资源的更新需要被监控。如果被监控的资源被更新了那么该资源所对应的web应用将会被重新装载。这个元素的内容必须是一个String。
Special Features Logging
从前面给出的 体系结构图 中可以看出，Logging特性在Engine、Host和Context中都有支持。这个特性使得我们可以区分日志记录的具体来源。 在Engine、Host和Context中的日志类别分别为： org.apache.catalina.core.ContainerBase.[enginename]
org.apache.catalina.core.ContainerBase.[enginename].[hostname]
org.apache.catalina.core.ContainerBase.[enginename].[hostname].[path] 其中中括号([])中为具体的名称。
Logging特性的实现是通过org.apache.catalina.core.ContainerBase来完成的。
Access Logs
从前面给出的 体系结构图 中可以看出，Access Logs特性在Engine、Host和Context中都有支持。
Engine中的Access Logs记录所有Engine处理的请求的访问日志 Host中的Access Logs记录所有Host处理的请求的访问日志 Context中的Access Logs记录所有Context处理的请求的访问日志 一般的配置方法是在conf/server.xml文件的相关元素中加入：
上面的
如果您要了解Access Log Valve设置的更多信息，可以查阅这里。
Lifecycle Listeners
从前面给出的 体系结构图 中可以看出，Lifecycle Listeners特性在Engine、Host和Context中都有支持。这个特性使得我们可以方便的进行生命周期的管理。
值得一提的是在Tomcat的标准实现中Server和Service也支持生命周期的管理，但是在官方文档中没有显著的说明，所以没有在图中体现出来。细节可以查阅Server和Service部分。
Engine中的Lifecycle Listeners监听该Engine的生命周期事件(Eifecycle Event) Host中的Lifecycle Listeners监听该Host的生命周期事件(Eifecycle Event) Context中的Lifecycle Listeners监听该Context的生命周期事件(Eifecycle Event) 一般的配置方法是在conf/server.xml文件的相关元素中加入：
上面的
Request Filters
从前面给出的 体系结构图 中可以看出，Request Filters特性在Engine、Host和Context中都有支持。
Engine中的Request Filters过滤所有Engine处理的请求 Host中的Request Filters过滤所有Host处理的请求 Context中的Request Filters过滤所有Context处理的请求 一般的配置方法是在conf/server.xml文件的相关元素中加入：
上面的 如果您要了解Remote Address Filter设置的更多信息，可以查阅这里。 如果您要了解Remote Host Filter设置的更多信息，可以查阅这里。 Automatic Application Deployment 从前面给出的 体系结构图 中可以看出，Automatic Application Deployment特性只在Host中都有支持。 如果使用Host的标准实现，同时deployOnStartup属性值为true(这是默认值)，那么Catalina在首次启动时会自动完成下面的工作：