J2SE 1.4 and 1.5 都包含了一个XML处理解析器的Java API 。Bootstrap 类加载器加载这个解析器的类文件，所以这个解析器会优先于任何一个安装在CLASSPATH里的解析器 被加载，即使您已经安装了新版本的解析器。标准覆盖机制允许您重写JAVA_HOME/lib/endorsed文件夹里某些特定的类(例如CORBA 和 JAXP 类)。Bootstrap 类加载器将会优先加载这些类。想详细了解此机制，请访问http://java.sun.com/j2se/1.5.0/docs/guide/standards/ 。
有关类加载的一些有趣的注意事项如下所示：
?只有当一个类具有包名、类名以及加载此类文件的类加载器的实例的时候，一个类才会被认为完全合格。换句话说，同样的类被两个不同的类加载器加载，会被认为是两个不同的类。即使在同一个JVM中，这已影响到这个类实例的分配、静态属性或单例的处理。
?一个类加载器只能看到位于它层次结构上面的类的目录。例如，一个Extension文件夹里的 JAR不能使用应用程序类路径里的类文件。这是因为，Extension文件夹里的类只能看到Extension类加载器以及Bootstrap 类加载器可以加载的类。
?当一个类的代码中引用了另一个类时，加载引用类的类加载器同样也会加载被引用的 类，这称为自定义类加载器。一个类的自定义类加载器可以使用Class.getClassLoader()来获得。
?每个线程都有一个上下文类加载器，使用Thread.currentThread().getContextClassLoader()可以查看到。每次一个新的线程被创建，这个新线程的上下文类加载器会被设置到它的创建线程。main()线程的类加载器是应用程序类加载器，它会自动向下传播到每个工作线程，除非您通过调用
Thread.currentThread().setContextClassLoader() 进行干预。
在JavaEE的范畴里这种模式显得有些别扭。
首先，Servlet容器需要为web应用提供一个限制环境。
如果某个servlet直接使用系统类加载器（System Calss Loader），那么该servlet会看到启动Tocmat时所使用JVM命令中所使用的path下的所有类。这是有潜在安全风险的，因为恶意应用（部署在同一个主机商的主机上的应用）可能被允许加载到其兄弟节点上的web应用的类。正是因为如此，每个web应用必须有自己的类加载器，而该类加载器位于类加载器树的根节点并且可以优先加载在web应用的目录WEB-INF/classes以及WEB-INF/lib下所发现的类。
当所请求加载的类是java标准时，该自定义类加载器将只委托其父类加载器来加载；如果一个web应用还需要其他的类，那么这个自定义类加载器不是去委托其父类去加载，而是首先检查WEB-INF/classes以及WEB-INF/lib中是否包含该类。只有在这两个目录都找不到时，该类加载器才会委托给其父类加载器来加载，而父类加载器的的加载遵循标准委托模式。（译注：类加载相关知识请看文章末尾）。
Tomcat的额外类加载器
在启动过程中，Tomcat首先通过清除CLASSPATH并将其重新指向CATALINA_HOME/bin/bootstrap.jar（Tomcat启动所需的类）、tomcat-juli（日志功能）、tools.jar（jsp编译功能）来屏蔽系统类加载器（System ClassLoader）。这使得系统类加载器只有在加载一小部分Tomcat特殊类时才起作用。
同时Tomcat也改变了支持目录并将其重新指向CATALINA_HOME/endorsed目录。
在其自定类加载器之下，Tomcat又增加了它自己的类加载器，这其中包括server类加载器（Server class loader）、共享类加载器（Shared class loader）、通用类加载器（Common class loader）以及每个部署的应用程序都有的一个web应用程序类装入器。
当一个web应用需要加载一个类时，请求首先发送至web应用的类加载器，该加载器负责加载web应用中WEB-INF/classes和WEB-INF/lib两个目录下的类。
web应用类加载器首先会请求系统类加载器来允许各层类加载器可以查找所有java核心类。当所请求的类未找到到时，该web应用类加载器会尝试从自身类库中定位所请求的类；如果仍然未找到，它将委托通用类加载器或者如果有共享类加载器时委托共享类加载器来加载。
共享类加载器和服务器类加载器默认情况下是没有安装的，但是我们可以通过编辑 CATALINA_HOME/conf/catalina.properties文件通过增加shared.loader和server.loader来开启共享类加载器以及server类加载器；而Common类加载器会监控CATALINA_HOME/lib目录的内容，该下为一些蝉蛹的jar包，比如servlet-api.jar, jasper.jar, coyote.jar, and jsp-api.jar。此外，位于共享目录下的类将对所有web应用可见，但不是Tomcat的内部类，而放在服务器的loader目录的类将只对Tomcat内部类可见。
使Tomcat支持类重载的web应用特定类加载器。
当context需要被新部署或者当一个类需要被重载时（例如当一个被重新编译过的类文件加入到WEB-INF/classes目录时），整个web应用的类加载器都会被抛弃，然后创建一个新的实例分支来加载该web应用的所有类。该新的类加载就是用来为之后的请求服务的。
server.xml中的logger元素在Tomcat5.5中就已经被弃用；所以在Tomcat6中是基于Java1.4中所引入的日志API来生成日志的。
然而Java日志只能在整个JVM级别来进行配置，而不能对每个类加载器单独配置。为了使每个web应用程序都能允许不同的配置文件，Tomcat实现了自定义的Java日志，这就是我们所熟知的JULI，该实现位于CATALINA_HOME/bin/tomcat-juli.jar中。
全局的配置文件CATALINA_HOME/conf/logging.properties控制着日志设置。此外，每个web应用也可以有自己的日志配置文件WEB-INF/classes/logging.properties。
如上图所示，日志由一下组件组成：
●Logger：所有的日志请求会进入Logger对象。这些对象都按层次排列，其根在根logger；同时这种层次结构也反映了包结构。在该层次中属性可以被绑定到任何级别上，而且Logger的子类也会继承器父类属性。
●Handler：指定日志消息应该发送何处。可选的有ConsoleHandler（将日志写入控制台）、FileHandler（将日志写入文件）、SocketHandler（将日志写入Tcp socket）。
●Level(日志级别)：日志级别有其中：SEVERE、WARNING、INFO、CONFIG、FINE、FINER、FINEST、OFF（禁用）、ALL（记录所有信息），每种级别决定了需要记录何种类型的消息。
●Formatter（日志格式化）：该元素决定了信息以什么格式展示。Tomcat提供了SimpleFormatter、XMLFormatter两种格式化工具。
和web应用上下文相关的资源包括静态资源，如类文件、HTML、JSP、CSS文件。这些资源可能以不同的格式存在。默认情况下，Tomcat支持从war格式的压缩文件(译注：war包)或者解压过的war中查找资源文件。
可想而知,一个上下文中的资源也可能从替代存储机制中访问,比如JDBC数据库。而资源组件使之成为可能。
Tomcat同时也提供基于目录服务的JNDI API，该服务可支持从未知存储方式中读取资源。
这里讲了很多，现在我们需要做的就是使自己理解Tomcat架构总览中所讲解的东西。在这篇文章里，我们讨论了一些Tomcat的核心组件，看到了一个运行中的Tomcat实例是如何由各种顶级组件、连接器（Connector）以及嵌套组件构建起来的。
1. 本文由程序员学架构翻译
2. 本文译自
https://www.packtpub.com/books/content/overview-tomcat-6-servlet-container-part-2
3. 转载请务必注明本文出自：程序员学架构(微信号：archleaner)
4. 更多文章请扫码：
原文地址：http://blog.csdn.net/archleaner/article/details/43917629
