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

发布于 2024-08-19 21:46:16 字数 946 浏览 8 评论 0原文

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

我在使用 OSGi (Equinox 3.4.2) 时遇到的最常见问题之一是线程的上下文类加载器经常不可用。我知道这部分是 Equinox 问题，但我也遇到了 Felix 的问题。我遇到这种情况主要是在启动自己的线程或线程池的第三方库中。当它们在 Bundle 或 DS 激活期间启动时，它们最终可能会没有 ClassLoader。如果第 3 方库可以防止上下文 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 是否不为空，并且不重写上下文类加载器。

现在，我将这段代码粘贴到各个地方，我知道某些第 3 方库可能会产生一个线程并毁掉我的一天。虽然一开始是可以处理的，但我最终在很多随机的地方都遇到了这个问题，这让我很困扰。

还有其他人遇到这个问题吗？他们想出了什么解决方案？我还想了解这个问题是否在新的 Equinox 3.5.x 中得到解决，以及是否有人真正看到它起作用？

问候。

原文

I've been using OSGi for a while now and I have various solutions to the problems I encountered. I wanted to revisit one of these and see if people had come up with different solutions.

One of the most common issues I have with OSGi (Equinox 3.4.2) is the frequent unavailability of the Thread's context ClassLoader. I know this is partly an Equinox problem, but I have encountered the issue with Felix as well. I encounter this mostly with 3rd party libraries that start their own Threads or ThreadPools. When these are started during Bundle or DS activation, they can end up without their ClassLoader. If the 3rd party library has guards against the context ClassLoader being missing, then no problem, but not everyone checks it. Later, if the said library needs to do dynamic classloading it might blow up.

The idiom I have been using for a while is the following (briefly):

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

This idiom usually ends up in the Activator or the DS activate() method. There are some minor variations where I do check whether tccl is not null and I don't override the context classloader.

Now, I have a this bit of code plastered into various places where I know some 3rd party library might spawn a Thread and ruin my day. While it was manageable at first, I have ended up having this in many random places and it's bothering me.

Anybody else suffering from this issue, and what solutions have they come up with? I would also like to get an idea of whether this problem is solved in the new Equinox 3.5.x, and whether anyone has actually seen it work?

Regards.

分享到QQ

分享到微博