更好地处理OSGi中的Thread Context ClassLoader

Question

我一直在使用OSGi一段时间,我遇到了各种问题的解决方案.我想重新审视其中一个,看看人们是否提出了不同的解决方案.

我与OSGi(Equinox 3.4.2)最常见的问题之一是Thread的上下文ClassLoader经常不可用.我知道这部分是一个Equinox问题,但我也遇到了Felix的问题.我遇到的主要是第三方库启动自己的Threads或ThreadPools.当这些在Bundle或DS激活期间启动时,它们最终可能没有它们的ClassLoader.如果第三方库有防止上下文ClassLoader丢失,那么没问题,但不是每个人都检查它.后来,如果所述库需要进行动态类加载,它可能会爆炸.

我已经使用了一段时间的成语如下(简要):

ClassLoader tccl = Thread.currentThread().getContextClassLoader();
try {
    Thread.currentThread().setContextClassLoader(getClass().getClassLoader());
    /*
     * Start threads, or establish connections, here, now
     */
} finally {
    Thread.currentThread().setContextClassLoader(tccl);
}

这个习惯用法通常最终出现在Activator或DS activate()方法中.有一些小的变化,我检查是否tccl不为空,我不会覆盖上下文类加载器.

现在,我有一些代码贴在各个地方,我知道一些第三方库可能会产生一个线程并破坏我的一天.虽然一开始它是可以管理的,但我最终在许多随机的地方都有这个,这让我感到烦恼.

还有其他人遇到这个问题,他们提出了什么解决方案？我还想知道在新的Equinox 3.5.x中是否解决了这个问题,是否有人真正看到它有效？

问候.

Answer 1

很棒的问题,我们一直在做同样的工作(在Felix/Karaf/Servicemix4.2中),并一直在寻找更好的解决方案.以下是我从Felix团队回来的回复......

http://old.nabble.com/Can-the-thread-context-classloader-issue-be-solved-at-all--td28260809.html#a30704352

从本质上讲,他们说目前没有更好的解决方案.

但是,我确实看到Equinox引用了其他一些选项,包括"Buddy Policies"和在这里使用"Context Finder"......

http://wiki.eclipse.org/Context_Class_Loader_Enhancements

如果有人知道其他选项甚至路线图以便将来解决此问题,请告诉我们......