WAS的类加载机制二

12．2 概览Websphere 类加载器

注意：每一个JVM都有自己的类加载器。在WebSphere 环境中会有多个应用程序服务器（JVM）,也就是说JVM的类加载器是分开的，尽管它们运行在同一个物理机器上。

还需要注意的是：Java虚拟机(JVM) 使用的扩展和应用程序类加载器，你能够看到WebSphere 运行环境也使用名为扩展和应用程序类加载器，尽管它们的名字有些一致，但它们和JVM使用的是不一样的。

WebSphere 提供了几个客户化委托类加载器，如下图12-2：

图12-2 Webspere 类加载器层次图

最顶端的方框表示Java类加载器（引导、扩展和应用程序）。WebSphere 在这里加载它自己的引导类加载器和初始化WebSphere扩展类加载器。

12．2．1 WebSphere 扩展类加载器

V6.1新特性: WebSphere 扩展类加载器是WebSphere 加载自己的地方。在WebSphere之前的版本，运行环境被单一的类加载器加载。然而，从WAS6.1开始，WebSphere 被打包成若干OSGi（Open Services Gateway Initiative） 包。每一个OSGi 包都由自己的类加载器加载。OSGi 类加载器的网络通过OSGi网关类加载器跟扩展类加载器和类加载器层次结构中的其余部分相连。

    不管WebSphere装入自己类的方式如何改变，应用程序也不会有改变。还是同样的可见性、同样的类加载选择。

V6.1新特性:在WAS之前的版本中，WebSphere运行时类文件保存在<was_home>目录下的classes、lib、lib\ext和installedChannels 目录下。由于OSGi包，这些目录都不存在了，运行时类文件会存放在<was_home>\plugins 目录下。

扩展类加载器的类路径是由ws.ext.dirs 系统属性指定，也就是setupCmdLine 脚本文件中指定的WAS_EXT_DIRS环境变量设置。ws.ext.dirs 的缺省值如例12-3：

例12-3 we.ext.dirs 的缺省值

SET

WAS_EXT_DIRS=%JAVA_HOME%\lib;%WAS_HOME%\classes;%WAS_HOME%\lib;%WAS_HOME%\insta

lledChannels;%WAS_HOME%\lib\ext;%WAS_HOME%\web\help;%ITP_LOC%\plugins\com.ibm.e

tools.ejbdeploy\runtime

ws.ext.dirs 环境变量中列出的每个路径都会被添加到WebSphere扩展类加载器的类路径中，并且该目录中的每个JAR文件和ZIP文件都会被添加到类路径中。

正如所看到的，尽管在<was_home>目录中不再有classes、lib、lib\ext 和installedChannels文件夹，但是setupCmdLine 脚本文件会把它们添加到扩展类路径中。这就意味着，如果之前你已经把自己的JAR文件添加到<was_home>\lib 目录下，你可以创建这个目录并且把JAR文件添加进去，它们依然会被扩展类加载器加载。然而，不推荐这么做，在安装过程中还是正确的迁移比较好。

另一方面，如果你已经开发了Java应用程序，它依赖之前在<was_home>\lib 目录下的WebSphere JAR文件，你需要让你的程序保留兼容性。WAS 6.1 针对这样的应用程序提供了两种瘦客户端库：管理客户端库和Web 服务客户端库。可以在<was_home>\runtimes 目录下面找到这两个客户端库：

_ com.ibm.ws.admin.client_6.1.0.jar

_ com.ibm.ws.webservices.thinclient_6.1.0.jar

这些库为应用程序提供了连接和与WebSphere一起工作的所有内容。

缺省设置是Allow，意思是你的应用程序可以无限制的调用非公用的内部WebSphere 类。但是不推荐这么使用，在未来的版本这个功能可能会被限制。因此，作为管理员，如果应用程序还能正常运行，最好把这个设置改成Restrict。如果它们依赖非公用的WebSphere内部类，你就收到一个ClassNotFoundException，这样还得改成Allow。这样开发人员就需要对应用程序进行移植，以保证应用程序能够兼容未来的WAS版本。

V6.1新特性:WAR 6.1 限制对WebSphere内部类的访问，这样你的程序才不会依赖那些未公开发布的WAS 的API。这个设置针对每个服务器(JVM)，称为访问内部服务器类。

12．2．2 应用程序和Web模块类加载器

J2EE 应用程序包含五个主要元素：Web 模块，EJB 模块，应用程序客户端模块，资源适配器（RAR文件），工具JAR。工具JAR包含了EJB 和Servlet使用的代码。log4j  就是一个好的典型的工具框架的例子。EJB 模块、工具JAR、资源适配器文件和应用程序关联的共享库都会归结到同一个类加载器。这个类加载器称为应用程序类加载器。根据类加载器的规则，缺省情况下，多个应用程序（EAR）可以共享这个类加载器或者每一个应用程序都有对应的类加载器。

缺省情况下，Web 模块使用它们自己的类加载器（WAR类加载器）加载WEB-INF/classes 和EB-INF/lib 目录下的内容。通过修改应用程序WAR类加载策略可以改变这个缺省情况。

缺省情况，应用程序中每个WAR文件都有自己的类加载器（早期的版本，这个设置称为 Module）。如果WAR类加载策略设置成Single（早期的版本称为Application）类加载器，除了EJB、RAR、工具JAR以及共享库之外，Application类加载器还加载Web模块的内容。Application类加载器是WAR类加载器的父亲。Application类加载器和WAR类加载器都是可重装入的类加载器。一旦它们自动监测到程序代码改变了，就会重装入修改的类。我们可以在部署应用程序的时候改变这个行为。

12．2．3 操纵JNI 代码

因为JVM只有一个地址空间，每个地址空间中native代码只能装入一次，JVM规范要求在JVM中native代码只能被一个类加载器加载。

例如，这将导致一个问题，如果你有一个包含两个Web模块的应用程序（EAR文件），两个Web模块都需要通过Java Native Interface（JNI）装入native 代码，那么只有第一个被加载的Web模块能够成功。

为了解决这个问题，你可以把加载到类中的native 代码拆分成多个Java代码并且把它放在WebShpere应用程序类加载器（放在工具JAR）中。然而，如果要在同一个应用程序(JVM)中部署多个这样的应用程序(EAR文件)，你需要把类文件放到WebSphere扩展类加载器上，取代每个JVM只能加载一次native代码。

如果native 代码放在一个可加载的类加载器（比如应用程序类加载器或者WAR类加载器），有一点很重要：能够正确的卸载自己的native代码而Java代码能够重加载。WebSphere 无法控制native代码，如果native代码不能正确的卸载或者加载，应用程序可能失败。

    如果native 库依赖另一个，事情就会变得很复杂。关于native库的依赖关系，请查看信息中心。

12．3 配置 WebSphere 类加载器

在之前的内容中，我们了解了WebSphere 类加载器以及类加载器如何协同工作。这一部分我们会讨论如何修改WAS的配置来影响Websphere类加载的行为。