类加载器的父类委托及DGService框架中ejb调用的分析

前边DGService框架在部署调用ejb的后台服务时，总是提示ClassNotFoundException这样的异常，所以花时间对虚拟机的类加载器的加载机制也研究了一下。

这里先简单的说一下类加载器的机制及其父类委托模式。

类加载器负责把类加载到Java虚拟机（JVM）中。指定类的名称，类加载器就会定位这个类的定义，每一个Java类必须由类加载器加载。

当启动JVM的时候，可以使用三个类加载器：引导（bootstrap）类加载器、扩展（extensions）类加载器、应用程序（application）类加载器。

1.引导类加载器仅仅负责加载核心的Java库，比如位于<JAVA_HOME>/jre/lib 目录下的vm.jar，core.jar。这个类加载器，是JVM核心部分，是用native代码写成的。

2. 扩展类加载器负责加载扩展路径下的代码，一般位于<JAVA_HOME>/jre/lib/ext  或者通过java.ext.dirs 这个系统属性指定的路径下的代码。这个类加载器是由sun.misc.Launcher$ExtClassLoader 实现的。

3.应用程序类加载器负责加载java.class.path（映射系统参数 CLASSPATH的值） 路径下面的代码，这个类加载器是由 sun.misc.Launcher$AppClassLoader 实现的。

当处理类加载器时，父委托模式是一个需要理解的关键概念。它规定：类加载器在加载自己的类之前，可以委托先加载父类。父类加载器可以是客户化的类加载器或者引导类加载器。但是有一点很重要，类加载器只能委托自己的父类加载器，而不能是子类加载器（只能向上不能向下）。

扩展类加载器是应用程序类加载器的父亲。

如果应用程序类加载器需要加载一个类，它首先委托扩展类加载器，扩展类加载器再委托引导类加载器。如果父类加载器不能加载类，子类加载器就回在自己的库中查找这个类。基于这个特性，类加载器只负责它的祖先无法加载的类。

如 果类加载器加载一个类，这个类不是在类加载器树上的叶子节点上，就会出现一些有趣的问题。

 

类加载器的图示：

 

DGService中的后台服务热部署技术，就是通过在类加载器这一层做文章来实现的。我们的后台服务程序，是使用自定义的类加载器来加载的。但是，在后台服务中，调用ejb的时候，需要用到javax.naming.InitialContext这个类，而这个类是在jdk里的，自定义类加载器委托它的父类加载器去加载，父类加载器在jdk相关的包里找到了这个类，并进行了加载。这个时候javax.naming.InitialContext是被应用程序类加载器加载的。而在InitialContext调用了weblogic.jndi.WLInitialContextFactory这个类，基于被调用类和调用类使用同一类加载器这个原则，那么虚拟机会使用应用程序类加载器而不是我们在DGService里自定义的类加载器去加weblogic.jndi.WLInitialContextFactory这个类，但是weblogic.jndi.WLInitialContextFactory这个类是位于weblogic.jar包里的，也就是我们认为的第三方包，放在ext目录中。对于我们自定义的类加载器来说，ext目录下的jar包是位于类路径上的，但是对于应用程序类加载器来说，ext目录就不是类路径。所以，虚拟机再使用应用程序类加载器进行类加载并使用父类委托机制时，最终还是找不到这个类，所以ClassNotFoundException这个异常就被抛出了。还有一种情况就是发生ClassCastException，就是类型转换异常，这个大家都明白，把一种类型转换为强制转换为另外一种类型时，最有可能是向下转型的时候出现这种异常。但是，在DGService应用中，就是另外一种情况了，比如你把weblogic.jar设置了应用程序类加载器的类路径，而ejb调用的客户端放在了ext目录中，就会发生这种异常。检查代码肯定一点问题都没有，而且类型也不会错，但是确实报这种异常了，原因何在呢？其实，除了向下转型中出现这种异常，在不同类加载器加载的类之间进行转换，同样也会产生这样的异常。因为，ejb调用的相关代码的类是应用程序类加载器加载的，而ejb的客户端类是使用自定义类加载器加载的，这样就出现了ClassCastException异常。

所以，一个解决办法就是，我们把weblogic.jar以及ejb调用的客户端相关包放入lib目录下，并在startup.bat里指定类路径，也就是说，我们要把ejb调用的相关jar包设置为应用程序类加载器的类路径，这样就避免了ClassNotFoundException和ClassCastException异常。这样虽然解决了问题，但也带来了新的问题，也就是我们的jar包不能热部署，如果替换了，必须重新启动后台服务管理器。所以，最终的解决方案还是在我们自定义的类加载器下功夫，使用jndi技术来实现数据源，ejb等资源的加载，从而彻底解决ClassNotFoundException和热部署这一对矛盾。