Hazelcast在OSGI中的classloading问题

前些日子在开发中用到了hazelcast，挺不错的一个DD支持分布式map,list等多种容器，并且实现了标准的JDK容器接口，实在是太赞了。和Spring配合使用，应该很是方便，测试的时候set一个标准的JDK容器实现，避免跑测试程序是每次启动hazelcast，影响测试运行速度，运行时注入真正的IMap,IList实例，很是的方便。

很是不幸的是。整个系统框架是基于OSGI的，因为Hazelcast是经过对象的序列化，从本机传输到远端， 在远端反序列化，来实现对象实例在再不一样JVM之间的传输的。因而在OSGI严格的classloading机制下，各类ClassNotFound Exception 出现了。

在网上查了一下，发现hazcelcast声称已经解决了这个问题，有些帖子测试没问题，有些帖子测试有问题。。有点混乱。在咱们的环境下是对于map,list等容器没问题，对于executorservice,topic等Hazelcast有内部线程控制，有问题。

研究了一下当前的版本1.9.3发现，对于Map，list等容器类的实现，classloader采用的是当前线程的context class loader, 这点是很是巧妙的，由于当前线程必定能Load到目标集合中的类对象，这点也是Hazelcast针对OSGI ClassLoading问题的官方fix,（fix 以前原来使用的是configClassLoader, 简单的说就是hazelcast初始化线程的context class loader）.假设bundle A建立了hazelcast（hazelcast的默认classloader即为A的bundle class loader），bundle B 中取得了一个 hazelcast map对象，向其中放了一个bean（bundle B 的类，没有export） 对象,再取出， 此时若是hazelcast若是使用默认的classloader load bean 对象必定会出 class not found exception, 经过使用current thread 的context class loader（当前线程在B bundle中，固然能load 到本身的类）， hazelcast的fix巧妙的解决了这个问题。

可是对于executorservice,topic等有hazelcast内生线程管理的服务，因为服务的内部线程池都是在Hacelcast初始化的时候预先建立，因此统一使用configClassLoader,因而若是你的hazelcast是在bundle A 中建立好的，而后bundle B 中向executorservice添加了一个Brunnable对象，恭喜你，即便在hazelcast单机模式下，一样会出现ClassNotFound Exception。由于如今hazelcast的内部线程使用的都是默认configClassLoader（Ａ的bundle class loader）。

在这种状况下只能经过dynamic import * 来解决问题。。

结论

1.hazelcast和osgi在一块儿工做挺难的，若是使用executorservice,topic等组件。

2.若是非要用。。。最好在使用exceutor service 或者 topic的bundle中首次初始化hazelcast,这样能够避免不少潜在的问题。