懂得WebLogic Server应用程序类加载

Java 类加载

类加载器是 Java 语言的基本模块。类加载器是 Java 虚拟机 (JVM) 的一部分，它会将类加载到内存中；类加载器负责在运行时查找和加载类文件。每个成功的 Java 编程人员都需要了解类加载器及其行为。本部分概述 Java 类加载器。

Java 类加载器层次结构

类加载器包含具有父类加载器和子类加载器的层次结构。父类加载器和子类加载器之间的关系类似于超类和子类之间的对象关系。引导类加载器是 Java 类加载器层次结构的根。Java 虚拟机 (JVM) 创建引导类加载器，它将加载 JVM 中包含的 Java Development Kit (JDK) 内部类和 java.* 包。（例如，引导类加载器加载 java.lang.String。）

扩展类加载器是引导类加载器的子类加载器。扩展类加载器加载 JDK 的扩展目录中包含的所有 JAR 文件。这是一种无需在类路径中添加条目即可扩展 JDK 的便捷方法。但扩展目录中的所有内容都必须是自包含的，且只能引用扩展目录中的类或 JDK 类。

系统类路径类加载器扩展 JDK 扩展类加载器。系统类路径类加载器加载 JVM 类路径中的类。应用程序特定的类加载器（包括 WebLogic Server 类加载器）是系统类路径类加载器的子类加载器。

加载类

类加载器在加载类时使用委托模型。类加载器实现首先检查其缓存，查看是否已经加载所请求的类。由于不重复从磁盘中加载类，而是使用该类在缓存内存中的副本，所以，这种类验证可以提高性能。如果在类缓存中找不到该类，则当前类加载器会要求其父类加载器提供该类。仅当父类加载器也无法加载该类时，该类加载器才会尝试加载该类。如果某个类既存在于父类加载器中，又存在于子类加载器中，则将加载父类加载器中的类。遵循这种委托模型可以避免同时加载多份相同的类。加载多份相同的类会引发 ClassCastException。

类加载器会先要求其父加载器加载类，然后再尝试自己加载该类。可以对 WebLogic Server 中与Web 应用程序关联的类加载器进行配置，使其首先在本地进行检查，然后再要求其父类加载器提供该类。这样，Web 应用程序能够使用其自己版本的第三方类，这些类也可能包含于 WebLogic Server 产品中。prefer-web-inf-classes 元素部分将详细讨论。

prefer-web-inf-classes 元素

weblogic.xml Web 应用程序部署描述符中包含 <prefer-web-inf-classes> 元素（<container-descriptor> 元素的子元素）。默认情况下，该元素设置为 False。将该元素设置为 True 会颠反类加载器委托模型，以便优先加载 Web 应用程序中的类定义，其次才加载更高一级的类加载器中的类定义。这使得 Web 应用程序能够使用自己版本的第三方类，这些类也可能包含于 WebLogic Server 中。请参阅 weblogic.xml 部署描述符元素。

使用此功能时必须谨慎，不要混淆通过 Web 应用程序类定义创建的实例与通过服务器定义创建的实例。如果混淆这些实例，则会引发 ClassCastException。

清单 8-1 说明 prefer-web-inf-classes 元素及其描述与默认值。

/** 

* 如果为 true，位于 web-app 的 WEB-INF 目录中的类
* 在加载时优先于在应用程序或系统类加载器中
* 加载的类。
* @default false
*/ 

boolean isPreferWebInfClasses(); 

void setPreferWebInfClasses(boolean b);

更改正在运行的程序中的类

通过 WebLogic Server，您可以在服务器运行期间部署更新版本的应用程序模块，例如 EJB。这个过程即是所谓的热部署或热重新部署，它与类加载紧密相关。

Java 类加载器没有用于取消部署或卸载一组类的标准机制，也不能加载新版本的类。为更新正在运行的虚拟机中的类，必须将已加载该更改类的类加载器替换为新的类加载器。替换类加载器时，必须重新加载通过该类加载器（或该类加载器的任何子类加载器）加载的所有类。这些类的所有实例都必须重新实例化。

在 WebLogic Server 中，每个应用程序都具有类加载器的层次结构，它们是系统类加载器的子类加载器。这些层次结构允许单独重新加载应用程序或应用程序的各个部分，而不影响系统的其他部分。WebLogic Server 应用程序类加载讨论了此主题。

?

WebLogic Server 应用程序类加载

以下部分概述 WebLogic Server 应用程序类加载器：

WebLogic Server 应用程序类加载的概述

WebLogic Server 类加载以应用程序的概念为核心。应用程序通常打包为企业归档 (EAR) 文件，其中包含应用程序类。EAR 文件中的所有内容均被视为同一个应用程序的组成部分。下面的内容可以作为 EAR 的一部分，也可以作为独立应用程序进行加载：

如果分别部署 EJB 和 Web 应用程序，会将它们视为两个应用程序。如果将它们一起部署在 EAR 文件中，则它们是一个应用程序。可以将模块共同部署于一个 EAR 文件内，以便系统将它们视为同一个应用程序的各部分。

每个应用程序都接收其自己的类加载器层次结构；该层次结构的父级是系统类路径类加载器。这可以隔离应用程序，以使应用程序 A 无法查看应用程序 B 的类加载器或类。在层次结构类加载器中，不存在同级或同伴的概念。应用程序代码只能看到与该应用程序（或模块）关联的类加载器所加载的类，以及应用程序（或模块）类加载器的父类加载器所加载的类。这允许 WebLogic Server 在同一个 JVM 中承载多个隔离的应用程序。

应用程序类加载器层次结构

部署应用程序时，WebLogic Server 自动创建类加载器的层次结构。该层次结构的根类加载器将加载应用程序中的所有 EJB JAR 文件。将针对每个 Web 应用程序 WAR 文件创建子类加载器。

由于 Web 应用程序通常会调用 EJB，所以 WebLogic Server 应用程序类加载器体系结构允许 JavaServer Page (JSP) 文件和 servlet 查看其父类加载器中的 EJB 接口。这种体系结构还允许在不重新部署 EJB 层的情况下重新部署 Web 应用程序。实际上，通常会更改 JSP 文件和 servlet，而不更改 EJB 层。

下图说明此 WebLogic Server 应用程序类加载的概念。

?

如果您的应用程序包含使用 EJB 的 servlet 和 JSP：

尽管可以分别部署 WAR 和 JAR 文件，但如果将它们共同部署于 EAR 文件内，则会生成允许 servlet 和 JSP 查找 EJB 类的类加载器安排。如果分别部署 WAR 和 JAR 文件，WebLogic Server 将为它们创建同级类加载器。这表明您必须在 WAR 文件中包含 EJB Home 接口和远程接口，且 WebLogic Server 必须针对 EJB 调用使用 RMI 存根和骨架类，如同 EJB 客户端和实现类位于不同 JVM 中一样。 下一部分应用程序类加载和按值传递或按引用传递中将详细讨论该概念。

自定义模块类加载器层次结构

可以为应用程序创建自定义类加载器层次结构，从而更好地控制类是否可见以及是否可重新加载。可以通过在 weblogic-application.xml 部署描述符文件中定义 classloader-structure 元素来实现自定义。

下图说明如何 WebLogic 应用程序默认的类加载器组织结构。具有应用程序级类加载器，它可以加载所有 EJB 类。对于每个 Web 模块，都有适用于该模块的类的独立子类加载器。

为了简化起见，下图中不说明 JSP 类加载器。

?

该层次结构对于多数应用程序都具有最佳效果，因为在调用 EJB 时，它支持使用 call-by-reference 语义。它还允许独立重新加载 Web 模块，而不影响其他模块。而且，它允许其中一个 Web 模块中运行的代码加载任任 EJB 模块中的类。这很方便，因为 Web 模块不必包含其使用的 EJB 的接口。注意，严格来说，其中某些优点并不能与 Java EE 兼容。

创建自定义模块类加载器的功能提供了声明备用类加载器组织的一种机制，从而支持下列操作：

声明类加载器层次结构

可以在 WebLogic 特定的应用程序部署描述符 weblogic-application.xml 中声明类加载器层次结构。

该声明的 DTD 如下：

<!ELEMENT classloader-structure (module-ref*, classloader-structure*)>

<!ELEMENT module-ref (module-uri)>

<!ELEMENT module-uri (#PCDATA)>

weblogic-application.xml 中的顶级元素包含一个可选的 classloader-structure 元素。如果不指定该元素，则将使用标准类加载器。同时，如果某特定模块未包含于定义中，则将按照标准层次结构的定义为其分配一个类加载器。即，EJB 模块与应用程序“根”类加载器关联，而 Web 应用程序模块具有自己的类加载器。

通过 classloader-structure 元素，可以嵌套 classloader-structure 节，以便您描述类加载器的任意层次结构。当前限制为三级嵌套。最外层的条目指明应用程序类加载器。对于未列出的模块，将使用标准层次结构。

有关 DTD 元素的详细信息，请参考企业应用程序部署描述符元素。

下面是一个类加载器声明（在 weblogic-application.xml 中的 classloader-structure 元素中定义）的示例：

<classloader-structure> 

	<module-ref> 

		<module-uri>ejb1.jar</module-uri> 

	</module-ref> 

	<module-ref> 

		<module-uri>web3.war</module-uri> 

	</module-ref>

	<classloader-structure> 

		<module-ref> 

			<module-uri>web1.war</module-uri> 

		</module-ref> 

	</classloader-structure>

	<classloader-structure> 

		<module-ref> 

			<module-uri>ejb3.jar</module-uri> 

		</module-ref> 

		<module-ref> 

			<module-uri>web2.war</module-uri> 

		</module-ref>

		<classloader-structure> 

			<module-ref> 

				<module-uri>web4.war</module-uri> 

			</module-ref> 

		</classloader-structure> 

		<classloader-structure> 

			<module-ref> 

				<module-uri>ejb2.jar</module-uri> 

			</module-ref> 

		</classloader-structure>

	</classloader-structure>

</classloader-structure>

嵌套的组织结构指明类加载器的层次结构。以上各节将形成下图所示的层次结构。

?

用户定义类加载器的限制

通过用户定义的类加载器限制，可以更好地控制可重新加载的类，还可以提供模块内的类的可见性。此功能主要供开发人员使用。它适用于迭代开发，但不建议在生产应用中使用此功能的重新加载功能，因为如果更新中包含无效元素，则可能会损坏正在运行的应用程序。可以在生产中应用名称空间隔离和类可见性的自定义类加载器安排。但程序员应明确知晓，Java EE 规范要求应用程序不依赖于任何给定的类加载器组织。

某些类加载器层次结构会导致应用程序内的模块的行为如同两个独立应用程序中的模块。例如，如果将 EJB 置于其自己的类加载器中，以便对其分别加载，则您将获得 call-by-value 语义，而不是 BEA 在标准类加载器层次结构中提供的 call-by-reference 优化。同时请注意，如果您使用自定义层次结构，可能会遇到过期引用而结束。因此，如果您重新加载 EJB 模块，也应该重新加载其调用模块。

创建用户定义的模块类加载器层次结构还有些限制；将在以后部分中讨论。

禁用 Servlet 重新加载

如果使用自定义类加载器层次结构，在该特定应用程序中，将对 Web 应用程序禁用 servlet 重新加载。

嵌套深度

嵌套仅限于三级（包括应用程序类加载器）。更深级别的嵌套将引发部署异常。

模块类型

自定义类加载器层次结构目前仅限用于 Web 和 EJB 模块。

重复项

重复项将引发部署异常。

接口

标准 WebLogic Server 类加载器层次结构将为应用程序中的所有模块提供 EJB 接口。因此，即使其他模块自身并不包含接口类，也可以调用 EJB。这是可能的，因为 EJB 始终加载至根类加载器中，而所有其他模块或者共享该类加载器，或者其类加载器是该根类加载器的子类加载器。

通过自定义类加载器功能，您可以配置类加载器层次结构，以使调用方无法看到被调用方的类。在这种情况下，调用模块必须包含接口类。调用其他应用程序中的模块时，此要求同样适用。

Call-by-Value 语义

随 WebLogic Server 提供的标准类加载器层次结构允许应用程序内各模块之间的调用使用 call-by-reference 语义。这是由于调用方始终使用同一类加载器或调用方的子类加载器。通过此功能，可以配置类加载器层次结构，以使两个模块位于类加载器树中的不同分支上。在这种情况下，会使用 call-by-value 语义。

正在进行的工作

务必小心，重新加载所需要的类加载器开关并不是模块之间的原子操作。实际上，应用程序的更新一般都不是原子操作。出于此原因，各种不同的正在进行的操作（进行更改的过程中发生的操作）很可能会因时机不同而最终访问不同版本的类。

仅用于开发

“仅用于开发”功能是针对开发应用提供的。由于更新不是原子操作，所以此功能不适用于生产应用。

实现类的单个 EJB 类加载器

WebLogic Server 允许您重新加载单独的 EJB 模块，而不要求您同时重新加载其他模块，也不必重新部署整个 EJB 模块。此功能类似于目前在 WebLogic Server servlet 容器中重新加载 JSP 的方式。

由于 EJB 类是通过接口调用的，所以可能将单独的 EJB 实现类加载到其自己的类加载器中。这样，可以单独地重新加载这些类，而不必重新部署整个 EJB 模块。下图显示单个 EJB 模块的类加载器层次结构的外观。模块包含两个 EJB（Foo 和 Bar）。这是前一部分中描述的应用程序一般层次结构的子树。

?

要对文件（相对于所展开应用程序的根）执行部分更新，请使用以下命令行：

java weblogic.Deployer -adminurl url -user user -password password 

-name myapp -redeploy myejb/foo.class

在 -redeploy 命令后，提供要更新的文件（相对于已展开的应用程序的根）列表。这可能是特定元素（如上）或模块（或任何一组元素和模块）的路径。例如：

java weblogic.Deployer -adminurl url -user user -password password 

-name myapp -redeploy mywar myejb/foo.class anotherejb

给定一组要更新的文件，系统将尝试计算重新部署所需要的最少内容。如果仅重新部署 EJB 实现类，则将仅重新部署该类。如果指定整个 EJB（在上例中为 anotherejb）或如果更改并更新 EJB Home 接口，则必须重新部署整个 EJB 模块。

该重新部署可能会导致其他模块也重新部署，具体取决于类加载器层次结构。特别是，如果其他模块共享 EJB 类加载器，或加载到该 EJB 的类加载器（如 WebLogic Server 标准类加载器模块中）的子类加载器中，则这些模块也将重新加载。

应用程序类加载和按值传递或按引用传递

现代编程语言使用两种常见参数传递模型：“按值传递”和“按引用传递”。通过“按值传递”，将为每个方法调用复制参数和返回值。通过“按引用传递”，将向方法传递实际对象的指针（或引用）。因为“按引用传递”可以避免复制对象，所以它可以提高性能，但它也提供了修改被传递参数状态的一种方法。

WebLogic Server 中包含一种优化方法，能够提高服务器内远程方法接口 (RMI) 调用的性能。它不使用“按值传递”以及 RMI 子系统的编组和解组工具，而是由服务器通过“按引用传递”直接调用 Java 方法。此机制大大提高了性能，还可用于 EJB 2.0 本地接口。

RMI 调用优化和按引用调用仅适用于调用方和被调用方位于同一个应用程序内的情况。同样，这也与类加载器相关。由于应用程序具有自己的类加载器层次结构，任何应用程序类都会在两个类加载器中定义，如果您尝试在应用程序之间进行分配，则会引发 ClassCastException 错误。为解决这个问题，WebLogic Server 在应用程序之间使用“按值调用”，即使应用程序位于同一个 JVM 中，也会使用该方法。

使用筛选类加载器

在 WebLogic Server 中，系统类路径中的全部 .jar 文件由 WebLogic Server 系统类加载器加载。服务器实例中运行的所有应用程序都在应用程序类加载器（系统类加载器的子类加载器）中加载。在系统类加载器的此实现中，应用程序不能使用系统类加载器中已有的不同版本的第三方 jar。每个子类加载器都会要求父类加载器（系统类加载器）提供特定的类，但不能加载父类加载器所见的类。

例如，如果 $CLASSPATH 以及应用程序 EAR 中都包含名为 com.foo.Baz 的类，则将加载 $CLASSPATH 中的类，而不加载 EAR 中的类。由于 weblogic.jar 位于 $CLASSPATH 中，应用程序无法替代任何 WebLogic Server 类。

以下部分定义并介绍如何使用筛选类加载器：

什么是筛选类加载器

FilteringClassLoader 提供一种机制，可用于对部署描述符进行配置，以明确指定：特定的包应始终从应用程序中加载，而不应由系统类加载器加载。这样，您可以使用其他版本的应用程序，例如 Xerces 和 Ant。

FilteringClassLoader 位于应用程序类加载器和系统之间。它是系统类加载器的子类加载器，也是应用程序类加载器的父类加载器。FilteringClassLoader 侦听 loadClass(String className) 方法，并将 className 与 weblogic-application.xml 文件中指定的一列包进行比较。如果该包匹配 className，则 FilteringClassLoader 会引发 ClassNotFoundException。该异常通知应用程序类加载器从应用程序中加载类。

配置 FilteringClassLoader

要配置 FilteringClassLoader，从而指定应从应用程序中加载特定的包，请向 weblogic-application.xml 文件中添加 prefer-application-packages 描述符元素，该文件详细列出要从应用程序中加载的包。下例指定 org.apache.log4j.* 和 antlr.* 包应从应用程序中加载，而不从系统加载器中加载：

<prefer-application-packages>

  <package-name>org.apache.log4j.*</package-name>

  <package-name>antlr.*</package-name>

</prefer-application-packages>

资源加载顺序

资源加载顺序是 java.lang.ClassLoader 的 getResource()方法和 getResources() 方法返回资源的顺序。启用筛选时，该顺序与禁用筛选时的顺序稍有不同。启用筛选表示 FilteringClassLoader中包含一个或多个包模式。不使用任何筛选（默认）时，将按照类加载器树的自上而下的顺序收集资源。例如，如果 Web (1) 请求资源，资源分组的顺序为：系统 (3)、应用程序 (2) 和 Web(1)。请参阅图 8-5。

系统 (3)

|

应用程序 (2)

|

Web (1)

为使说明更明确，给定一个资源 /META-INF/foo.xml，它位于所有类加载器中且会返回下列 URL：

   META-INF/foo.xml - from the System ClassLoader (3)

   META-INF/foo.xml - from the App ClassLoader (2)

   META-INF/foo.xml - from the Web ClassLoader (1)

启用筛选时，将返回从 FilteringClassLoader（应用程序类加载器）的子类加载器到该调用类加载器中的资源，然后再返回系统类加载器中的资源。在图 8-6 中，如果同一资源位于所有类加载器 (D)、(B) 和 (A) 中，当 Web 类加载器请求该资源时，则将以如下顺序获得这些资源：

   META-INF/foo.xml - from the App ClassLoader (B)

   META-INF/foo.xml - from the Web ClassLoader (A)

   META-INF/foo.xml - from the System ClassLoader (D)

系统 (D)

|

FilteringClassLoader (filterList := x.y.*) (C)

|

应用程序 (B)

|

Web (A)

如果应用程序类加载器请求同一资源，将获得以下顺序。

   META-INF/foo.xml - from the App ClassLoader (B)

   META-INF/foo.xml - from the System ClassLoader (D)

getResource() 只返回第一个描述符，getResourceAsStream() 返回第一个资源的 inputStream。

?

解析模块和应用程序之间的类引用

应用程序可能使用多个不同的 Java 类，包括企业 Bean、servlet、JavaServer Pages、实用程序类以及第三方包。WebLogic Server 通过不同的类加载器部署应用程序，从而维护独立性，并简化动态重新部署和取消部署。因此，您应以正确的方式打包应用程序类，以使每个模块都可以访问其所依赖的类。在某些情况下，可能必须在多个应用程序或模块中包含一组类。本部分描述 WebLogic Server 如何使用多个类加载器，以便您能够成功地临时保存应用程序。

关于资源适配器类

现在每个资源适配器都使用其自己的类加载器加载类（类似 Web 应用程序）。结果，诸如 Web 应用程序和 EJB 等与应用程序归档（EAR 文件）中的资源适配器一起打包的模块无法访问资源适配器中的类。如果需要此类访问，则必须将资源适配器类放置在 APP-INF/classes 下。还可以归档这些类（使用 JAR 实用工具），并将它们放置在应用程序归档的 APP-INF/lib 下。

确保您的 WebLogic Server 系统类路径中不包含任何资源适配器特定的类。如果 Web 模块（例如，EJB 或 Web 应用程序）需要使用资源适配器特定的类，则您必须将这些类绑定在相应模块的归档文件（例如，EJB 的 JAR 文件或 Web 应用程序的 WAR 文件）中。

打包共享的实用工具类

WebLogic Server在 EAR 文件提供了一个存储共享实用工具类的位置。将实用工具 JAR 文件放置在 APP-INF/lib 目录下，将各个类放置在 APP-INF/classes 目录下。（不要将 JAR 文件放置在 /classes 目录下，或将类放置在 /lib 目录下。）这些类将加载到应用程序的根类加载器中。

通过此功能，不必将实用工具类放置在系统类路径中，也不必将类放置在 EJB JAR 文件内 （取决于标准 WebLogic Server 类加载器层次结构）。请注意，使用此功能与使用前一部分所述的清单类路径稍有不同。使用此功能，可以在应用程序内共享类定义。而使用清单类路径，只是简单扩展了引用模块的类路径，这表明，每个模块都有各自的类副本。

清单类路径

Java EE 规范提供清单类路径条目，模块可以使用该方式指定其需要辅助类的 JAR。仅当您的 EJB JAR 或 WAR 文件中包含其他支持 JAR 文件时，才需使用清单类路径条目。在这种情况下，当您创建 JAR 或 WAR 文件时，您应包含清单文件，其中指明引用所需 JAR 文件的 Class-Path 元素。

下面是简单的清单文件，其中引用 utility.jar 文件：

Manifest-Version: 1.0 [CRLF]
Class-Path: utility.jar [CRLF]

在清单文件的第一行，必须始终包含 Manifest-Version 特性，再另起一行 (CR | LF |CRLF)，然后是 Class-Path 特性。有关清单格式的详细信息，请访问：http://java.sun.com/j2se/1.4/docs/guide/jar/jar.html#JAR

清单 Class-Path 条目指相对于对这些条目进行定义的当前归档的其他归档。该结构支持多个 WAR 文件和 EJB JAR 文件共享公用库 JAR。例如，如果 WAR 文件中包含的一个清单条目为 y.jar，该条目应位于 WAR 文件旁边（而不是在其中），如下：

<directory>/x.war

<directory>/y.jars

清单文件自身应位于 META-INF/MANIFEST.MF 下的归档中。

有关详细信息，请参阅 http://java.sun.com/docs/books/tutorial/jar/basics/manifest.html。

?

通过使用 Java EE 库共享应用程序和模块

Java EE 库提供了一种简单方式，可以在多个企业应用程序之间共享一个或多个不同类型的 Java EE 模块。Java EE 库是已在部署时向 Java EE 应用程序容器注册的单个模块或一组模块。有关详细信息，请参阅创建共享 Java EE 库和可选包。

?

在系统类路径中添加 JAR

WebLogic Server 包含一个 lib 子目录，它位于域目录下，可以用于当服务器启动时向 WebLogic Server 系统类路径中添加一个或多个 JAR 文件。lib 子目录用于存放更改频繁的 JAR 文件，服务器中部署的所有或大多数应用程序或 WebLogic Server 本身都需要该子目录。例如，可以使用 lib 目录来存储域中所有部署都需要的第三方实用工具类。还可以使用它将修补程序应用到 WebLogic Server。

不建议将 lib 目录用于一般用途，例如，在域中部署的一个或两个应用程序之间共享 JAR，或共享需要定期更新的 JAR。如果更新 lib 目录中的 JAR，必须重新引导该域中的所有服务器，应用程序才能实现该更改。如果需要在若干应用程序之间共享 JAR 文件或 Java EE 模块，请使用创建共享 Java EE 库和可选包中描述的 Java EE 库功能。

要使用 lib 库共享 JAR，请执行下列操作：

from:http://middleware123.com/weblogic/docs100/programming/classloading.html