当前位置:首页 >> 计算机软件及应用 >>

Java类加载器以及Websphere的类加载器说明


类加载器说明 1 问题来源
ESB 中读取版本号的信息是从 version.properties 文件中读取,但是部署在 websphere 上 就是读取不到版本号的信息。采用的方式如下:
public static String getVersion() { //直接使用 Log4j 中的 Loader 来加载 URL versionFileURL = Loader.getResource("version.properties"); return doConfigure(versionFileURL).getProperty("version"); } public static Properties doConfigure(java.net.URL configURL) { log.debug("Reading configuration from URL " + configURL); Properties props = new Properties(); InputStream istream = null; URLConnection uConn = null; try { uConn = configURL.openConnection(); uConn.setUseCaches(false); istream = uConn.getInputStream(); props.load(istream); } catch (Exception e) { if (e instanceof InterruptedIOException || e instanceof InterruptedException) { Thread.currentThread().interrupt(); } log.error("Could not read configuration file from URL [" + configURL + "].", e); log.error("Ignoring configuration file [" + configURL + "]."); } finally { if (istream != null) { try { istream.close(); } catch (InterruptedIOException ignore) { Thread.currentThread().interrupt(); } catch (IOException ignore) { } catch (RuntimeException ignore) { } } } return props; }

其中的 Loader 直接使用的是 log4j 中的类,它查找资源的方式如下: 1. 首先使用 Thread.currentThread().getContextClassLoader()类加载器去加载资源文件 2. 如果没找到就使用当前类的加载器即 Loader.class.getClassLoader()去加载资源 从打出来的日志信息来看 URL 的路径信息为: jar:file:/opt/WebSphere/AppServer/java/jre/lib/ext/healthcenter.jar!/version.properties 即获取到的资源文件为 jre 的 ext 目录下的 version.properties 文件。为什么会出现这种情况 呢?那么就需要了解 java 的类加载器和 websphere 的类加载器的原理。

1

2 JVM 的类加载器
2.1 类加载器的层次结构

类加载器树状组织结构示意图。左右两幅图是等价的
? ? ?

?

引导类加载器(bootstrap class loader) :它用来加载 Java 的核心库,是用原生代码 来实现的,并不继承自 java.lang.ClassLoader。 扩展类加载器(extensions class loader) :它用来加载 Java 的扩展库。Java 虚拟机 的实现会提供一个扩展库目录。该类加载器在此目录里面查找并加载 Java 类。 系统类/应用类加载器(system/Application class loader) :它根据 Java 应用的类路径 (CLASSPATH)来加载 Java 类。一般来说,Java 应用的类都是由它来完成加载的。 可以通过 ClassLoader.getSystemClassLoader()来获取它。 自定义类加载器,一般是继承系统类加载器

2.2 类加载器的行为方式
Java 中的类加载器加载某个类是采用父类优先,委托代理的方式进行加载。 类加载器在尝试自己去查找某个类的字节代码并定义它时, 会先代理给其父类加载器, 由父 类加载器先去尝试加载这个类, 依次类推直到引导类加载器, 而如果引导类加载器没有找到, 则由扩展类加载器去加载,如果还是没有,则最后由系统类加载器去加载。那么为什么要这 么做呢?在介绍之前需要了解 JVM 中是如何判定两个类是否相同的。 Java 虚拟机不仅要看类的全名是否相同,还要看加载此类的类加载器是否一样。只有两者 都相同的情况,才认为两个类是相同的。即便是同样的字节代码,被不同的类加载器加载之 后所得到的类,也是不同的。试图对这两个类的对象进行相互赋值,会抛出运行时异常

ClassCastException。
代理模式的设计动机是为了保证 Java 核心库的类型安全,所有 Java 应用都至少需要引用 java.lang.Object 类,也就是说在运行的时候,java.lang.Object 这个类需要被加载到 Java 虚 拟机中。如果这个加载过程由 Java 应用自己的类加载器来完成的话,很可能就存在多个版 本的 java.lang.Object 类,而且这些类之间是不兼容的。通过代理模式,对于 Java 核心库的
2

类的加载工作由引导类加载器来统一完成,保证了 Java 应用所使用的都是同一个版本的 Java 核心库的类,是互相兼容的。

2.3 类加载的过程
在前面介绍类加载器的代理模式的时候, 提到过类加载器会首先代理给其它类加载器来尝试 加载某个类。这就意味着真正完成类的加载工作的类加载器和启动这个加载过程的类加载 器,有可能不是同一个。真正完成类的加载工作是通过调用 defineClass 来实现的;而启动 类的加载过程是通过调用 loadClass 来实现的。前者称为一个类的定义加载器(defining loader) ,后者称为初始加载器(initiating loader) 。在 Java 虚拟机判断两个类是否相同的时 候,使用的是类的定义加载器。也就是说,哪个类加载器启动类的加载过程并不重要,重要 的是最终定义这个类的加载器。 两种类加载器的关联之处在于: 一个类的定义加载器是它引 用的其它类的初始加载器。如类 com.example.Outer 引用了类 com.example.Inner,则由类 com.example.Outer 的定义加载器负责启动类 com.example.Inner 的加载过程。 方法 loadClass()抛出的是 java.lang.ClassNotFoundException 异常;方法 defineClass()抛出的 是 java.lang.NoClassDefFoundError 异常。 类加载器在成功加载某个类之后,会把得到的 java.lang.Class 类的实例缓存起来。下次再请 求加载该类的时候, 类加载器会直接使用缓存的类的实例, 而不会尝试再次加载。 也就是说, 对于一个类加载器实例来说, 相同全名的类只加载一次, 即 loadClass 方法不会被重复调用。

3

2.4 JVM 类加载器例子
public class WhichClassLoader1 { public static void main(String[] args) throws javax.naming.NamingException { // Get classpath values String bootClassPath = System.getProperty("sun.boot.class.path"); String extClassPath = System.getProperty("java.ext.dirs"); String appClassPath = System.getProperty("java.class.path"); // Print them out System.out.println("Bootstrap classpath =" + bootClassPath + "\n"); System.out.println("Extensions classpath =" + extClassPath + "\n"); System.out.println("Application classpath=" + appClassPath + "\n"); WhichClassLoader1 wcl1 = new WhichClassLoader1(); WhichClassLoader2 wcl2 = new WhichClassLoader2(); // Who loaded what? System.out.println("WCL1 was loaded by " + wcl1.getClass().getClassLoader()); System.out.println("WCL2 was loaded by " + wcl2.getClass().getClassLoader()); wcl2.getTheClass(); } } public class WhichClassLoader2 { // This method is invoked from WhichClassLoader1 public void getTheClass() { WhichClassLoader3 wcl3 = new WhichClassLoader3(); System.out.println("WCL3 was loaded by " + wcl3.getClass().getClassLoader()); } } public class WhichClassLoader3 { }

1. 如果上述三个类在应用的路径下,则都会被 AppClassloader 加载,能够正常执行。输 出的结果如下:

4

Bootstrap classpath =E:\Program Files\Java\jdk1.7.0_25\jre\lib\resources.jar;E:\Progra m Files\Java\jdk1.7.0_25\jre\lib\rt.jar;E:\Program Files\Java\jdk1.7.0_25\jre\lib\sunrsa sign.jar;E:\Program Files\Java\jdk1.7.0_25\jre\lib\jsse.jar;E:\Program Files\Java\jdk1.7. 0_25\jre\lib\jce.jar;E:\Program Files\Java\jdk1.7.0_25\jre\lib\charsets.jar;E:\Program Fi les\Java\jdk1.7.0_25\jre\lib\jfr.jar;E:\Program Files\Java\jdk1.7.0_25\jre\classes Extensions classpath =E:\Program Files\Java\jdk1.7.0_25\jre\lib\ext; Application classpath=.;E:\Program Files\Java\jdk1.7.0_25\jre\lib\charsets.jar;E:\Progra m Files\Java\jdk1.7.0_25\jre\lib\deploy.jar;E:\Program Files\Java\jdk1.7.0_25\jre\lib\ja vaws.jar;E:\Program Files\Java\jdk1.7.0_25\jre\lib\jce.jar;E:\Program Files\Java\jdk1.7. 0_25\jre\lib\jfr.jar;E:\Program Files\Java\jdk1.7.0_25\jre\lib\jfxrt.jar;E:\Program Files\J ava\jdk1.7.0_25\jre\lib\jsse.jar;E:\Program Files\Java\jdk1.7.0_25\jre\lib\managementagent.jar;E:\Program Files\Java\jdk1.7.0_25\jre\lib\plugin.jar;E:\Program Files\Java\jdk 1.7.0_25\jre\lib\resources.jar;E:\Program Files\Java\jdk1.7.0_25\jre\lib\rt.jar;E:\Progra m Files\Java\jdk1.7.0_25\jre\lib\ext\access-bridge.jar;E:\Program Files\Java\jdk1.7.0_2 5\jre\lib\ext\dnsns.jar;E:\Program Files\Java\jdk1.7.0_25\jre\lib\ext\jaccess.jar;E:\Progr am Files\Java\jdk1.7.0_25\jre\lib\ext\localedata.jar;E:\Program Files\Java\jdk1.7.0_25\ jre\lib\ext\sunec.jar;E:\Program Files\Java\jdk1.7.0_25\jre\lib\ext\sunjce_provider.jar;E: \Program Files\Java\jdk1.7.0_25\jre\lib\ext\sunmscapi.jar;E:\Program Files\Java\jdk1. 7.0_25\jre\lib\ext\sunpkcs11.jar;E:\Program Files\Java\jdk1.7.0_25\jre\lib\ext\zipfs.jar; WCL1 was loaded by sun.misc.Launcher$AppClassLoader@1835282 WCL2 was loaded by sun.misc.Launcher$AppClassLoader@1835282 WCL3 was loaded by sun.misc.Launcher$AppClassLoader@1835282 2. 如果将类 WhichClassLoader2 打包进一个 jar 如 a.jar, 将 a.jar 置于路径 Extensions classpath 下,而 WhichClassLoader1,和 WhichClassLoader3 仍然在应用路径下,再执行则会出错:

WCL1 was loaded by sun.misc.Launcher$AppClassLoader@1835282 WCL2 was loaded by sun.misc.Launcher$ExtClassLoader@9df354 Exception in thread "main" java.lang.NoClassDefFoundError: WhichClassLoader3 at WhichClassLoader2.getTheClass(WhichClassLoader2.java:8) at WhichClassLoader1.main(WhichClassLoader1.java:22) Caused by: java.lang.ClassNotFoundException: WhichClassLoader3 at java.net.URLClassLoader$1.run(URLClassLoader.java:366) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at java.lang.ClassLoader.loadClass(ClassLoader.java:357)

5

这是因为尽管 WhichClassLoader3 在应用路径下,但是由于 WhichClassLoader1 在加载 WhichClassLoader2,首先委托扩展类加载器进行加载,扩展类加载器再委托引导类加载器 加载,而引导类加载器在其路径的 jar 包中没有找到对应的类,然后再由扩展类加载器加 载,而扩展类加载器在其路径的 jar 包中找到了对应的类,正常加载。 而一旦一个类被加载,这里指 WhichClassLoader2,那么这个类所依赖的其它类都会使用 和 当 前 类 相 同 的 加 载 器 去 加 载 ( 或 者 其 父 类 加 载 器 ) , WhichClassLoader3 是 在 WhichClassLoader2 中调用的, 因此它的类加载器为扩展类加载器或者引导类加载器, 而不 是应用类加载器。而在那两个类加载器对应的路径的 jar 中都找不到 WhichClassLoader3, 因此会抛出异常。 同理资源文件的加载: Properties p = new Properties(); p.load(MyClass.class.getClassLoader().getResourceAsStream("myApp.properties"));

如果类MyClass由扩展类加载器加载,而属性文件myApp.properties在类路径下,那么上述的 代码加载资源文件就会出错。

3 Websphere 的类加载器
注意每个 JVM 都有上面所描述的上那个类加载器, JVM 与 JVM 中的类加载器是互相独立的。 在 WebSphere 中每个应用服务器(application server)都是启动在独立的 JVM 中,因此即使它 们在同一台物理机上,但是它们的类加载器是完全隔离的。 WebSphere 中也有扩展类加载器和应用类加载器,但是和 JVM 中的概念是不一样的,后面 会进行说明。

6

可以看到 JVM 规范中的加载器,在这里的作用主要是起到能够是 WebSphere 服务器能够正 常启动,以及初始化 WAS 的 extensions class loader。

3.1 WAS 的扩展类加载器(extensions class loader)
WebSphere扩展类加载器就是加载WAS自身的,在6.1之前WAS的运行时环境就是由这个单一 的扩展类进行加载。而6.1之后,则采用OSGI的方式组织WAS的运行时环境,每个OSGi bundle 和其它的bundle是分离的,有自己独立的类加载器。[OSGI相关概念需要进一步查找资料] 扩展类加载器引用的路径为系统属性ws.ext.dirs对应的值,它是在脚本命令setupCmdLine中由 环境变量WAS_EXT_DIRS来设置的。缺省的值为: SET WAS_EXT_DIRS=%JAVA_HOME%\lib;%WAS_HOME%\classes;%WAS_HOME%\lib;%WA S_HOME%\installedChannels;%WAS_HOME%\lib\ext;%WAS_HOME%\web\help;%ITP_LO C%\plugins\com.ibm.etools.ejbdeploy\runtime

该路径中的所有 jar 或者 zip 文件都会加到 classpath 中。

3.2 Application 和 Web module 加载器
JEE5中规范中定义了五种主要的元素: Web modules, EJB?modules, application client
modules, resource adapters (RAR files), and utility JARs. Utility JARs 中包含的代码主要是供 EJBs and servlets使用。常见的Utility frameworks如log4j。 EJB modules, utility JARs, resource adapter files, 和 shared libraries associated with an application这些内容一般组织到同一个类加载器中加载。通常这个类加载器为application class loader. 根据不同的类加载的策略, 类加载器可以被不同的应用(EARs)共享或者每个应用的类加 载器都是独立的(缺省方式)。 缺省情况下, Web module通过WAR class loader去加载WEB-INF/classes and WEB-INF/lib目 录下的文件。可以通过修改配置来改变它的默认的行为。

7

如果将WAR class loader 的策略修改为单个类装入器(Single class loader for application), 则application class loader 除了加载上面提到的EJBs等之外,还会加载Web module中的内容。 application class loader是WAR class loader的父加载器。 另外对于JNI的处理这里特殊说明一下: 由于一个JVM只有一个地址空间, 本地代码(native code,如C++)在一个地址空间中只能被加载一 次。 因此在JVM的规范中规定本地代码在JVM中只有由一个类加载器加载一次。 但是如果是比较 复杂的应用,如一个EAR中包含两个WebModule,在这两个Web Module中都需要通过JNI来加 载同一份本地代码,这样只有先启动的一个WebModule才能够正常运行。如果想这两个Web Module都能够正常加载,则需要将加载本地代码相关的java代码提取出来放到application class loader所查找的路径中。如果是多个EAR都想加载同一份本地代码,则需要将其放到extensions class loader所查找的路径中来确保一个JVM中只加载一次。

8

3.3 类加载器的配置

如果应用程序服务器的类装入器策略(class loader policy)设置为单个(Single),则在一个 JVM 中 只会有一个 application class loader 去加载所有的 all EJBs, utility JARs, and shared libraries。 如 果 同 时 WAR class loader 的 策 略 也 被 设 置 为 单 个 类 加 载 器 (Single class loader for application),则 Web module 的内容也会被这个 application class loader 去加载。即应用服务 器中的所有应用都是由一个类加载器进行加载的。 如 果 类 装 入 器 策 略 (class loader policy) 设 置 为 多 个 (Mutiple), 则 每 个 应 用 都 会 有 自 己 的 application class loader 去加载它自己的 EJB 等。 下面这个例子说明类加载器策略的不同,类加载的方式也不同。如有两个应用 Application1 and Application2,它们运行在同一个应用服务器中,每个应用都包含有一个EJB module, 一个 utility JAR, 和两个 Web modules。 1. 在缺省配置下,即应用服务器的类加载器策略为多个(Mutiple),Web modules的类加载器策 略设置为Class loader for each WAR file in application。

9

2. 如果将WAR2-2的类加载器策略修改为单个类装入器,则结果如下:

可以看到WAR2-2中的内容由application class loader进行加载。即Util2.jar中的类可以访问到 WAR2-2中/WEB-INF/classes and /WEB-INF/lib目录中的类。 3. 在2的基础上,如果将应用服务器的类加载器策略为单个(Single),并且将WAR2-1的类加载 器策略设置为Single classloader for application。结果如下:

可以看到只有一个application class loader 加载Application1 和 Application2中的所有 class. 并且Util1.jar中的类可以访问EJB2.jar,Util2.jar, WAR2-1.war and WAR2-2.war中的 类,但是它不能访问WAR1-1 和 WAR1-2中的类。因为类加载器只会委托其父类加载器去
10

寻找对应的类,而不会委托其子类加载器。

3.4 类加载器顺序/委托模式
WAS 中应用服务器和具体的应用都可以设置类加载的顺序(class loader order),如下图所示:

有两种方式:
Classes loaded with parent class loader first(parent first) Classes loaded with local class loader(war class loader) first (parent last)
11

缺省的策略和标准的 JVM 的类加载器策略一致,即委托父类进行加载。而如果为 parent last, 则类加载器在加载类是会先从其自身的 class path 路径中寻找类。 在什么情况下需要修改类加载顺序的策略为 parent last?如对于如下的场景: 加入有一个应用类似前面提到的例子Application1。它使用log4j在EJB Module和两个Web Module中记录日志。假设每个module都有自己的log4j.properties。如果将log4j的jar包作为utility JAR,这样在EAR中只需要有log4j的jar包的一份拷贝。但是如果这么做的话,你会看到所有的 Module,包含Web Module都只会从EJB Module中加载它的log4j.properties,即Web Module中 的log4j.properties文件不起任何作用。这是因为Log4j被配置为utility JAR,当Web Module初始 化log4j时,log4j相关的类会被application class loader加载。Log4j会在其类路径中查找 log4j.properties ,最后会在EJB module找到。即使你在EJB module中不使用log4j来记录日志(当 然EJB Module中没有log4j.properties), 也不会加载Web Module中的log4j.properties文件。 这是 因为类加载器只会向其父类去加载相关的类,而不会找其子类加载器。 为了使EJB Module,以及Web Module能够各自使用各自的log4j.properties文件,可以采用如下 一些方法: 1. 创建一个独立的jar包,如Resource.jar,将其配置为utility JAR。将Module中的 log4j.properties全部转移到Resource.jar中, 并且给其不同的名称如war1-1_log4j.properties, war1-2_log4j.properties等。当module中初始化log4j时,给log4j指定初始化时需要的文件的 名称,而不是缺省的文件名log4j.properties。 2. log4j.properties文件的位置不变,如(/WEB-INF/classes), 在各个Web modules(/WEB-INF/lib)中增加log4j.jar。然后将Web modules 的class loading mode 的值 设置为Classes loaded with local class loader first (parent last)。这样当Web Module中初始 化log4j时,它会从当前的Module中加载log4j相关的类,log4j会从当前的classpath中查找 log4j.properties文件,也即在当前Web Module中。而当EJB module初始化log4j,是由 application class loader 来加载log4j相关的类,并且会在EJB1.jar 文件中找到 log4j.properties文件。 3. 将所有的log4j.properties文件合并。打包到Resource.jar中 单例模式的特殊说明: 单例模式只是保证这个类只会被初始化一次,这个一次只的是被每个 class loader。 如果你有一个单例模式的实现A在两个独立的Web modules中,则单例模式任然会根据A创建两 个独立的实例。因为两个Web Module是由两个不同的WAR class loader加载的。因此如果WAR

类装入器策略设置为Multi,需要当心单例模式的实现可能并不是想要的效果。

4 问题总结
获取 ESB 的版本号采用的是 log4j 中的类 Loader 去加载 version.properties 文件,它会根据当 前线程的上下文 classloader(Thread.currentThread().getContextClassLoader())去加载, 它的默认 值为 application class loader,因此会加载应用加载器所关联的路径上找 version.properties 文 件,而恰好 jre/lib/ext/healthcenter.jar!/version.properties 有这个文件,因此会读取这个文件 的路径。 因 此 为 了 解 决 这 个 问 题 只 能 将 version.properties 的 文 件 名 修 改 为 其 它 的 文 件 名 如 esb_version.properties。 而如果加载 version.properties 的方式为修改为:
12

Version.class.getClassLoader().getResourceAsStream(“version.properties”)。 则可以将 Web Module 的类加载顺序修改为 parent last。

5 参考文档
1. 深入探讨 Java 类加载器 2. http://space.itpub.net/?uid-14789789-action-viewspace-itemid-442016 3. websphere 调整类加载顺序的真正效果 4. WebSphere V7 Understanding ClassLoader

13


相关文章:
Java类加载器以及Websphere的类加载器说明_图文.doc
Java类加载器以及Websphere的类加载器说明 - 类加载器说明 1 问题
WebSphere服务器配置说明.doc
服务器配置| WebSphere服务器配置说明_IT/计算机_专业资料。WebSphere服务器配置...选择应用服务器 图:6.3 选择 java 和进程管理的 类装入器 图:6.4 选择新建...
eclipse+websphere配置说明.doc
eclipse+websphere配置说明_计算机软件应用_IT/...? 选择启用类重新装入,即实现类的热加载,下一步。...? 在修改 java 文件之后, 在加载 class 的过程中...
按步骤详细说明was(application WebSphere server)服务....doc
(application WebSphere server)服务器对cas证书生成、SSL配置、类加载、数据源...选择应用服务器 图:6.3 选择 java 进程管理的 类装入器 图:6.4 选择新建...
Websphere部署与配置手册.doc
进入方式: 服务器应用服务器server1java 管理和进程进程定义...>WebSphere6.1 如果没有找到 WebSphere6.1,只有 WebSphere6 的选项,说明 ...
WebSphere集群安装配置及部署应用说明[ND 6.1].doc
2) 修改应用程序的类加载方法为首先加载应用程序类。 10、 删除应用程序下的 ojdbc.jar 。使用 oracle 的 ojdbc.jar 放到 E:\WebSphere\AppServer\java\lib。...
JVM-类加载器.doc
类装载器的体系结构在 JAVA 虚拟机的安全性和网络...(只有一个参数), 使用调用者的类加载器来加载, ...web-infprefer-web-inf-classes 在 web 应用部署...
Java类加载器.pdf
Java 类 加载器的基本概念, 包括代理模式、 加载类的具体过程线程上下文类加载器等, 接着介绍如何开发自己的类加载器,最后介绍了类加载器在 Web 容器 OSGi?...
Java类的加载、链接和初始化_教育指南_百度教育攻略.pdf
IBM WebSphere Application Server则允许Web应用选择类加载器使用的策略。类加载器...因此,即便是同样的Java字节代码,被两个不同的类加载器定义之后,所得到的Java类...
Java程序中类加载完全揭密.pdf
一段代码来说明扩展开发属于 自己的类加载器的...类加载器 在 JVM 中, 每一个类都被 java.lang....同样,对于一个 web 服务器如果要丢 弃一个 ...
使用类加载器加载资源.txt
一但你把代码移到 EJB, Web 应用或 Java Web Start 应用中 , 一定会出问题...更严重的问题, 某些应用服务器把环境上下文当前类加载器设置到不同的类加载器...
Java程序类加载完全揭密.txt
演示一段代码来说明扩展开发属于自己的类加载器的...类加载器 在JVM中,每一个类都被java.lang.Class...同样,对于一个web服务器如果要丢弃一个servlet实例,...
websphere解决jar包冲突.doc
Jar 包冲突问题是在大型 Java 软件开发中经常遇到的问题,系统开发人员经常 会为...(class loader),为此,我们首 先介绍一下 WebSphere的类加载器以及一些相关...
类加载器.doc
现在类加载器Web 容器 OSGi 中得到了广泛的使用。一般来说,Java 应用的...基本上所有的类加载器都是 java.lang.ClassLoader 类的一个实例。下面详细 ...
Java深度历险(二)Java类的加载、链接和初始化.doc
一般来说,类加载器分成两类:启动类加载器(bootstrap)和用户 自定义的类加载器...IBM WebSphere Application Server 则允许 Web 应用选择类加载器使用的策略。 类...
Java动态类加载机制及其应用.pdf
务器(C/S)模式下动态地更新客户端软件功能的例子,说明了Java动态类加栽机制的...Java类是由类加载器负责加载的,ClassLoader类就是一个 基本的类加载器,它是用...
深入探讨Java类加载器.doc
深入探讨 Java 类加载器成富 IBM 中国软件开发中心...的类加载器, 最后介绍了类加载器在 Web 容器和 ...,Lotus?,Rational?,Tivoli?和 WebSphere?软件。 ?...
websphereV8使用说明.doc
websphereV8使用说明_计算机软件应用_IT/计算机_专业资料。WebSphereV8.05 安装...包括项目管理, 连接数据库, Java Servlet 代码生成器, beans 和 servlets 开发...
WebSphere培训_日常维护.ppt
服务器处于运行状态并且wsadmin也需要 用 户名密码...? 特别是关于类加载顺序的 配置。 更改应用的会话(...ps -ef |grep java 故障排查 WebSphere Application...
java编程思想-初始化与清理.txt
一个类加载器既可以自己完成Java类的定义任务, 也可以代理给其它的类加载器来...IBM WebSphere Application Server则允许Web应用选择类加载器运用的战略。 类加载...
更多相关标签: