为什么看起来OSGi-classloading被绕过了？

Question

我目前正在致力于使一些对OSGi非常不友好的第三方库可用于我们的OSGi-bundles。其中一个库(我已经使用bnd将其转换为捆绑包)设法加载它不能加载的类(至少通过OSGi-rules)。让我们假设这个包被称为Foo，它从中装载类的包名为bar。

Foo将bar作为可选导入。不过，这应该无关紧要，因为没有导出bar的包。我没有使用任何引导委派。但是，包含bar的应用程序框架位于应用程序类路径上(OSGi--file嵌入在我的应用程序中运行)。

显然，Foo以某种方式绕过了OSGi类加载基础设施。如何做到这一点？我非常确定它不使用自定义的类加载器，因为它没有理由有一个( Foo提供的任何特性都不需要这样的东西)。那么，捆绑包可以使用哪些标准的、开箱即用的方法来绕过OSGi类加载呢？

Answer 1

您使用的是什么OSGi框架？您是否有命令提示符命令或其他方式来请求有关包的详细信息？OSGi规范允许您详细研究，并且大多数框架都为OSGi PackageAdmin和其他API提供了匹配的命令/接口。

其他OSGi框架也会发生这种情况吗？

如果您使用ProSyst's mBedded Server作为OSGi框架，则可以使用以下命令发现谁正在从何处加载内容

pkginfo [<package>[ <package>]] -显示指定包的依存关系。如果没有参数，您将收到有关框架中所有可用包的信息。

Answer 2

如果类在应用程序类加载器上可用，这将会起到作用：

BundleContext.class.getClassLoader().loadClass("bar.X")

如果您可以通过加载器加载任何类，则可以获得所有其他类。当然，如果您运行的是security，您可以禁止访问类加载器。

Answer 3

好吧，下面是我的假设，没有证据。

实现非OSGi可选导入的最简单方法是使用Class.forName(name) -请注意没有classLoader的签名。让我们看一下这个的源代码：

return forName0(className, true, ClassLoader.getCallerClassLoader());

反过来，让我们看看ClassLoader.getCallerClassLoader()

...
Class caller = Reflection.getCallerClass(3);
...

3-是要调用的帧数(例如getCallerClass(0) -将返回反射类)。你可以很容易地计算哪些代码在堆栈中是#3，如果它不是由OSGi加载的，它将使用默认的classLoader。