更好地处理OSGi中的Thread Context ClassLoader [英] Better handling of Thread Context ClassLoader in OSGi
问题描述
我一直在使用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（））;
/ *
*启动线程，或建立连接，这里，现在
* /
} finally {
Thread.currentThread（）。setContextClassLoader（tccl）;
}
这个习惯用法通常以Activator或DS activate（）方式结束。有一些小的变化，我检查 tccl 是否为空，我不会覆盖上下文类加载器。
<现在，我有一些代码贴在各个地方，我知道一些第三方库可能会产生一个线程并破坏我的一天。虽然一开始它是可以管理的，但我最终在很多随机的地方都有这个，这让我感到烦恼。
其他人遇到这个问题，他们提出了哪些解决方案？我还想了解一下这个问题是否在新的Equinox 3.5.x中得到解决，以及是否有人真正看到它有效？
问候。
很棒的问题，我们一直在做相同的工作（在Felix / Karaf / Servicemix4.2中）并一直在寻找更好的解决方案。以下是我从Felix团队回复的回复...
基本上，他们说目前没有更好的解决方案。
但是，我确实看到Equinox引用了一些其他选项，包括Buddy Policies和在这里使用Context Finder......
http://wiki.eclipse.org/Context_Class_Loader_Enhancements
如果有人知道其他选项甚至路线图以便将来解决此问题，请告诉我们...
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.
Great question, we've been doing the same work around (in Felix/Karaf/Servicemix4.2) and have been searching for a better solution. Here is the response that I got back from the Felix team...
Essentially, they say that there isn't a better solution at the moment.
However, I do see that Equinox references some other options including "Buddy Policies" and using a "Context Finder" here...
http://wiki.eclipse.org/Context_Class_Loader_Enhancements
If anyone knows of other options or even a roadmap to resolve this in the future, please let us know...
这篇关于更好地处理OSGi中的Thread Context ClassLoader的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
