Kettle插件开发ClassCastException 解决思路

雨点打透心脏的1/2处 2022-07-16 02:18 308阅读 0赞

# 1.前言 #

最近在开发一个Kettle步骤插件的时候遇到**CCE(ClassCastException)**异常，在网上Google了很多资料，自己又调试了很久，才摸索出一些解决方法，分享给大家，相信对于经常开发Kettle插件的开发者难免会碰到这种奇葩的问题。

在开发调试过程中通过使用`-DKETTLE_PLUGIN_CLASSES`参数指定加载插件进行调试的时候并未报任何异常。然而，当我把插件打包部署到plugins目录下进行调试的时候，奇怪的异常就出现了：

Caused by: java.lang.ClassCastException: class org.apache.cxf.bus.spring.SpringBusFactory
        at java.lang.Class.asSubclass(Class.java:3208)
        at org.apache.cxf.BusFactory.newInstance(BusFactory.java:327)
        ... 31 more

当时就懵了，后来查阅了一些资料，调试了相关代码，发现通过指定`-DKETTLE_PLUGIN_CLASSES`参数调试插件的时候，插件使用的ClassLoader是`AppClassLoader`,而当插件部署到plugins目录使用的ClassLoader是Kettle自定义的ClassLoader -> `KettleURLClassLoader`。

> KettleURLClassLoader加载class的机制违反了传统的双亲委托机制，默认先从本地加载，加载不到的情况下才委托父级ClassLoader加载。原因是Kettle为了实现不同插件之间依赖库的隔离。

# 2.ClassCastException分析 #

**出现这个问题是因为不同的ClassLoader加载了相同的接口和实现类(包全名一致)，然后进行强制转换**。在JDK实现的ClassLoader机制(双亲委托)里，这种问题基本上不会存在，但是一旦应用中通过自定义ClassLoader来加载类并打破这种机制，就容易出现ClassCastException。很不幸，为了实现不同插件之间依赖库的隔离，Kettle自定义了KettleURLClassLoader并打破了双亲委托机制。**所以当你开发的插件依赖比较复杂，特别是用到了一些框架，如Spring、CXF等，这种情况就容易发生**。

> 打破JDK原有ClassLoader机制的自定义ClassLoader通常都是先从当前定义的ClassLoader加载，加载不到类的情况下再委托父classLoader里加载。

# 3.验证过程 #

在我开发的插件中需要用到CXF来调用webservice，由如下调用会出现上面提到的异常：

Bus bus = BusFactory.getDefaultBus();

根据前面给出的异常堆栈调试CXF`BusFactory`源码:

通过调试分析出异常路径为：

BusFactory.newInstance(String className) -> getBusFactoryClass(ClassLoader classLoader)

接下来注意getBusFactoryClass方法里面以下代码片段：

// .....
    
    if (isValidBusFactoryClass(busFactoryClass) 
        && busFactoryCondition != null) {
        try {
            Class<?> cls =  ClassLoaderUtils.loadClass(busFactoryClass, BusFactory.class)
                .asSubclass(BusFactory.class);
    
    // ....
        }
    
    }

debug断点进入Class.asSubClass()方法，我们就可以知道为何会抛出CCE异常了：

public <U> Class<? extends U> asSubclass(Class<U> clazz) {
        if (clazz.isAssignableFrom(this))
            return (Class<? extends U>) this;
        else
            throw new ClassCastException(this.toString());
    }

> asSubClass()方法的处理逻辑是：判断clazz是否为当前类的子类（注意必须是由同一个ClassLoder加载），如果是执行强制转换，否则抛出CCE异常。

当我的程序debug到该方法下，通过Eclipse Debug视图下的Expresssions增加并观察变量：

*  this

class org.apache.cxf.bus.spring.SpringBusFactory

*  this .getClassLoader()

sun.misc.Launcher$AppClassLoader@2c8fc809

*  clazz

class org.apache.cxf.BusFactory

*  BusFactory .class .getClassLoader()

org.pentaho.di.core.plugins.KettleURLClassLoader@31d7e3a9 : XXXX

*  clazz .isAssignableFrom(this)

false

到此已经可以很清楚的分析出，**产生CCE的原因是因为子类和父类是由不同的ClassLoader加载，尝试强制转换失败后抛出该异常**。

# 4.巧妙的解决方法 #

庆幸的是，许多的框架，如Spring、CXF加载Class使用的ClassLoader都是从当前线程的context class loader中获取：

Thread.currentThread().getContextClassLoader()

因此我们可以通过巧妙的方式绕过CCE，**通过临时设置当前线程的context loader为当前插件所使用的classloader(表示为KettleURLClassLoader类的对象)，然后在执行结束以后还原当前线程的context class loader**。示例如下：

Classloader originalClassloader = Thread.currentThread().getContextClassLoader();
    
    Thread.currentThread().setContextClassLoader(MyPluginClass.class.getClassLoader());
    
    ....//Execute library code
    
    Thread.currentThread().setContextClassLoader(originalClassloader);

Thread ConextClassLoader相当于JDK给我们提供了一个后门，可以让我们违背ClassLoader原来的设计模型：双亲委托模型，通过自定义的ClassLoader来加载类。

> 这种方式不知道是不是最合理的解决方案，因为我们必须无奈地在任何会出现CCE的调用前后植入临时设置context class loader的代码。

# 5.奇怪的LinkageError出现了 #

解决了CCE问题，也许问题不会到此结束，可能你还会遇到`LinkageError`：

java.lang.LinkageError: loader constraint violation: loader (instance of org/pentaho/di/core/plugins/KettleURLClassLoader) previously initiated loading for a different type with name "org/w3c/dom/Node"

**出现这种情况是由于一个ClassLoader加载了一个类，而后另外一个ClassLoader又加载了这个相同的类**。在前面CCE基础上出现这个问题我猜测是因为插件的ClassLoader先加载了自身依赖库中的一个类，而最后应用程序使用非插件ClassLoader(一般是AppClassLoader)加载同一个类，导致抛出这种异常。**我们可以猜测很有可能是因为jar包冲突，即插件的lib下某些jar可能与Kettle根目录下的lib下里的某些jar包冲突导致**。解决的办法是排除插件里面与kettle自带的那些冲突jar。

> 我们可以自己写一个小程序遍历两个目录下的jar包，分析比较出交集，交集即代表了冲突的jar。

在我开发的插件中存在以下jar包与Kettle lib包下面的jar包冲突：

*  commons-codec
 *  asm
 *  stax-api
 *  commons-logging
 *  xmlbeans
 *  wsdl4j
 *  xercesImpl
 *  xml-apis

我的解决方法就是在开发的插件中删掉这些jar包，使用Kettle lib下自带的jar就可以了。其实也就是让Kettle的ClassLoader(AppClassLoader)统一加载这个类，而不是插件的ClassLoader(KettleURLClassLoader)。

通过以上解决方法，事情也终于告一段落了。

# 6.参考 #

*  [深入浅出ClassLoader][ClassLoader]
 *  [How does the classloader for plugins differentiate from the standardjava classloader][]
 *  [classcastexception in kettle step][]
 *  [loader constraint violation - KettleURLClassLoader Job Plugin][]

[ClassLoader]: http://ifeve.com/classloader/
[How does the classloader for plugins differentiate from the standardjava classloader]: http://forums.pentaho.com/showthread.php?81995-How-does-the-classloader-for-plugins-differentiate-from-the-standardjava-classloader
[classcastexception in kettle step]: http://stackoverflow.com/questions/27694920/classcastexception-in-kettle-step
[loader constraint violation - KettleURLClassLoader Job Plugin]: http://forums.pentaho.com/archive/index.php/t-78045.html