类加载器操作指南

目录

概述

与许多服务器应用程序类似，Tomcat 安装了各种类加载器（即实现 java.lang.ClassLoader 的类），以允许容器的不同部分以及运行在容器上的Web应用程序访问不同的可用类和资源存储库。此机制用于提供 Servlet 规范版本 2.4 中定义的功能，特别是第 9.4 节和 9.6 节。

在 Java 环境中，类加载器以父子树的形式排列。通常，当类加载器被要求加载特定类或资源时，它会首先将请求委托给父类加载器，只有当父类加载器找不到请求的类或资源时，才会在自己的存储库中查找。请注意，Web应用程序类加载器的模型与此略有不同，如下所述，但主要原则是相同的。

当 Tomcat 启动时，它会创建一组类加载器，这些加载器按以下父子关系组织，其中父类加载器位于子类加载器之上

      Bootstrap
          |
       System
          |
       Common
       /     \
  Webapp1   Webapp2 ...

每个类加载器的特性，包括它们使其可见的类和资源的来源，将在下一节中详细讨论。

类加载器定义

如上图所示，Tomcat 在初始化时创建以下类加载器

  • Bootstrap — 此类加载器包含 Java 虚拟机提供的基本运行时类，以及存在于系统扩展目录 ($JAVA_HOME/jre/lib/ext) 中 JAR 文件中的所有类。注意：有些 JVM 可能会将其实现为多个类加载器，或者它可能完全不可见（作为类加载器）。

  • System — 此类加载器通常从 CLASSPATH 环境变量的内容初始化。所有此类类都对 Tomcat 内部类和 Web 应用程序可见。然而，标准 Tomcat 启动脚本 ($CATALINA_HOME/bin/catalina.sh 或 %CATALINA_HOME%\bin\catalina.bat) 完全忽略 CLASSPATH 环境变量本身的内容，而是从以下存储库构建 System 类加载器

    • $CATALINA_HOME/bin/bootstrap.jar — 包含用于初始化 Tomcat 服务器的 main() 方法及其所依赖的类加载器实现类。

    • $CATALINA_BASE/bin/tomcat-juli.jar 或 $CATALINA_HOME/bin/tomcat-juli.jar — 日志实现类。这包括 java.util.logging API 的增强类，称为 Tomcat JULI，以及 Apache Commons Logging 库的包重命名副本，Tomcat 内部使用。有关更多详细信息，请参阅日志文档。

      如果 tomcat-juli.jar 存在于 $CATALINA_BASE/bin 中，则使用它而不是 $CATALINA_HOME/bin 中的。这在某些日志配置中很有用

    • $CATALINA_HOME/bin/commons-daemon.jar — 来自 Apache Commons Daemon 项目的类。此 JAR 文件不存在于 catalina.bat|.sh 脚本构建的 CLASSPATH 中，但从 bootstrap.jar 的 manifest 文件中引用。

  • Common — 此类加载器包含对 Tomcat 内部类和所有 Web 应用程序都可见的附加类。

    通常，应用程序类不应放置在此处。此��加载器搜索的位置由 $CATALINA_BASE/conf/catalina.properties 中的 common.loader 属性定义。默认设置将按以下列出的顺序搜索以下位置

    • $CATALINA_BASE/lib 中解压的类和资源
    • $CATALINA_BASE/lib 中的 JAR 文件
    • $CATALINA_HOME/lib 中解压的类和资源
    • $CATALINA_HOME/lib 中的 JAR 文件

    默认情况下，这包括以下内容

    • annotations-api.jar — Jakarta Annotations 3.0 类。
    • catalina.jar — Tomcat Catalina Servlet 容器部分的实现。
    • catalina-ant.jar — 可选。用于处理 Manager Web 应用程序的 Tomcat Catalina Ant 任务。
    • catalina-ha.jar — 可选。提供基于 Tribes 的会话集群功能的高可用性包。
    • catalina-ssi.jar — 可选。服务器端包含模块。
    • catalina-storeconfig.jar — 可选。从当前状态生成 XML 配置文件。
    • catalina-tribes.jar — 可选。高可用性包使用的组通信包。
    • ecj-*.jar — 可选。用于将 JSP 编译成 Servlet 的 Eclipse JDT Java 编译器。
    • el-api.jar — 可选。EL 6.0 API。
    • jakartaee-migration-*-shaded.jar — 可选。提供从 Java EE 8 到 Jakarta EE 9 的 Web 应用程序转换。
    • jasper.jar — 可选。Tomcat Jasper JSP 编译器和运行时。
    • jasper-el.jar — 可选。Tomcat EL 实现。
    • jaspic-api.jar — Jakarta Authentication 3.1 API。
    • jsp-api.jar — 可选。Jakarta Pages 4.0 API。
    • servlet-api.jar — Jakarta Servlet 6.1 API。
    • tomcat-api.jar — Tomcat 定义的几个接口。
    • tomcat-coyote.jar — Tomcat 连接器和实用程序类。
    • tomcat-dbcp.jar — 可选。基于 Apache Commons Pool 2 和 Apache Commons DBCP 2 的包重命名副本的数据库连接池实现。
    • tomcat-i18n-**.jar — 可选的 JAR，包含其他语言的资源包。由于默认资源包也包含在每个单独的 JAR 中，如果不需要消息的国际化，可以安全地移除它们。
    • tomcat-jdbc.jar — 可选。另一种数据库连接池实现，称为 Tomcat JDBC 连接池。有关更多详细信息，请参阅文档。
    • tomcat-jni.jar — 提供与 Tomcat Native 库的集成。
    • tomcat-util.jar — Apache Tomcat 各组件使用的通用类。
    • tomcat-util-scan.jar — 提供 Tomcat 使用的类扫描功能。
    • tomcat-websocket.jar — 可选。Jakarta WebSocket 2.2 实现
    • websocket-api.jar — 可选。Jakarta WebSocket 2.2 API
    • websocket-client-api.jar — 可选。Jakarta WebSocket 2.2 客户端 API

  • WebappX — 为部署在单个 Tomcat 实例中的每个 Web 应用程序创建一个类加载器。Web 应用程序 /WEB-INF/classes 目录中所有解压的类和资源，以及 Web 应用程序 /WEB-INF/lib 目录下 JAR 文件中的类和资源，都对该 Web 应用程序可见，但对其他 Web 应用程序不可见。

如上所述，Web 应用程序类加载器与默认的 Java 委托模型有所不同（符合 Servlet 规范版本 2.4 第 9.7.2 节 Web 应用程序类加载器的建议）。当处理从 Web 应用程序的 WebappX 类加载器加载类的请求时，此类加载器会首先在本地存储库中查找，而不是在查找前委托。也有例外情况。属于 JRE 基本类的类不能被覆盖。还有一些例外，例如 XML 解析器组件，可以使用可升级模块功能进行覆盖。最后，Web 应用程序类加载器始终会优先委托给 Tomcat 实现的 Jakarta EE API 规范（Servlet、JSP、EL、WebSocket）的类。Tomcat 中的所有其他类加载器都遵循通常的委托模式。

因此，从 Web 应用程序的角度来看，类或资源加载按以下顺序在以下存储库中查找

  • 您的 JVM 的引导类
  • 您的 Web 应用程序的 /WEB-INF/classes
  • 您的 Web 应用程序的 /WEB-INF/lib/*.jar
  • System 类加载器类（如上所述）
  • Common 类加载器类（如上所述）

如果 Web 应用程序类加载器配置为 <Loader delegate="true"/>，则顺序变为

  • 您的 JVM 的引导类
  • System 类加载器类（如上所述）
  • Common 类加载器类（如上所述）
  • 您的 Web 应用程序的 /WEB-INF/classes
  • 您的 Web 应用程序的 /WEB-INF/lib/*.jar

XML 解析器与 Java

在旧版本的 Tomcat 中，您只需替换 Tomcat 库目录中的 XML 解析器即可更改所有 Web 应用程序使用的解析器。然而，当您运行现代 Java 版本时，此技术将无效，因为通常的类加载器委托过程总是优先选择 JDK 内部的实现。

Java 支持一种称为可升级模块的机制，以允许替换在 JCP 之外创建的 API（即 W3C 的 DOM 和 SAX）。它也可以用于更新 XML 解析器实现。

请注意，覆盖任何 JRE 组件都存在风险。如果覆盖组件未提供 100% 兼容的 API（例如，Xerces 提供的 API 与 JRE 提供的 XML API 不 100% 兼容），则 Tomcat 和/或部署的应用程序可能会出现错误。

高级配置

也可以配置更复杂的类加载器层次结构。参见下图。默认情况下，未定义 Server 和 Shared 类加载器，并使用上面显示的简化层次结构。通过在 conf/catalina.properties 中定义 server.loader 和/或 shared.loader 属性的值，可以使用这种更复杂的层次结构。


  Bootstrap
      |
    System
      |
    Common
     /  \
Server  Shared
         /  \
   Webapp1  Webapp2 ...

Server 类加载器仅对 Tomcat 内部可见，对 Web 应用程序完全不可见。

Shared 类加载器对所有 Web 应用程序可见，可用于在所有 Web 应用程序之间共享代码。但是，对此共享代码的任何更新都需要重启 Tomcat。