Java 在OSGi中更好地处理线程上下文类加载器

我使用OSGi已经有一段时间了，对于我遇到的问题，我有各种各样的解决方案。我想重温其中一个，看看人们是否提出了不同的解决方案

OSGi（Equinox 3.4.2）最常见的问题之一是线程的上下文类加载器经常不可用。我知道这在一定程度上是一个春分问题，但我也遇到了费利克斯的问题。我经常在第三方库中遇到这种情况，它们启动自己的线程或线程池。当这些在Bundle或DS激活期间启动时，它们可能最终没有类加载器。如果第三方库有防止上下文类加载器丢失的措施，那么没有问题，但不是每个人都检查它。稍后，如果所述库需要进行动态类加载，它可能会崩溃

我用了一段时间的成语如下（简要）：

这个习惯用法通常在Activator或DS activate（）方法中结束。有一些小的变化，我会检查

tccl

是否为null，并且我不会覆盖上下文类加载器

现在，我有一段这样的代码被粘贴到不同的地方，我知道一些第三方库可能会产生一个线程并毁掉我的一天。虽然一开始是可以控制的，但我在很多随机的地方都遇到了这种情况，这让我很困扰

还有其他人受到这个问题的困扰，他们想出了什么解决办法？我还想知道这个问题是否在新的Equinox 3.5.x版本中得到了解决，是否有人真的看到了它的工作原理

---

问候。

好问题，我们一直在做同样的工作（在Felix/Karaf/Servicemix4.2中），并一直在寻找更好的解决方案。这是我从Felix团队得到的回复

基本上，他们说目前没有更好的解决方案

然而，我确实看到Equinox引用了一些其他选项，包括“好友策略”和在这里使用“上下文查找器”

---

如果有人知道未来解决这一问题的其他方案或路线图，请让我们知道……

近一年来的第一个答案+1美元。但是是的，Felix团队推荐的是我已经在做的事情。上下文查找器是Equinox 3.6版本的，所以在提问时它不可用。然而，我曾尝试使用上下文查找器，但我发现它并不总是起作用。你可能至少从中获得了“风滚草”徽章：）不敢相信你没有得到任何回应，因为这似乎是OSGi的一个常见问题……今年是2020年。我也一直在寻找解决办法。也许第二个不被接受的解决方案会有所帮助？

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