如何使用单独的类加载器并在同一个 JVM 中运行? (OSGI)

发布于 2024-08-25 04:25:14 字数 199 浏览 8 评论 0原文

我读过 OSGI 每个模块使用单独的类加载器,这允许模块使用不同版本的依赖项......同时在同一个 JVM 中运行所有模块。

这是如何运作的?如果模块 A 使用依赖项的版本 #1,而模块 B 使用版本 #2,那么如果模块 A 将依赖项类的实例作为方法参数传递给模块 B,您不会遇到麻烦吗?

我认为如果模块 B 期望依赖类有一个不同的接口,它就会窒息。

I've read that OSGI uses separate classloaders per module which allows modules to use different versions of their dependencies.. while at the same time running all modules in the same JVM.

How does this work? If module A uses version #1 of a dependency and module B uses version #2, won't you run into trouble if module A passes an instance of the dependency class to module B as a method parameter?

I would think module B would choke if it was expecting a different interface to the dependency class.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

热情消退 2024-09-01 04:25:14

你是对的,不一致的依赖关系可能会导致问题。 OSGi 通过计算这些依赖关系的传递闭包并确保在解析时没有传递闭包来避免这种情况。

这允许您公开公共依赖项,同时具有内部/隐藏的私有依赖项,从而隐藏您的实现依赖项以避免这种情况。好处是,所有这些都是在捆绑解析时检查的,而不是模糊的运行时错误。

具体来说,在您的示例中,如果 A 和 B 使用不兼容的接口,并且 A 依赖于 B,则 A 将无法解析并出现依赖性错误。因此它甚至无法开始向其传递不兼容的类型。

You're right that inconsistent dependencies can cause problems. OSGi avoids this by calculating the transitive closure of these dependencies and ensuring that there are none at resolution time.

This allows you to expose a public dependency whilst having internal/hidden private dependencies and, as a result, hide your implementation dependencies to avoid this. The good thing is all thus is checked at Bundle resolution time rather than obscure runtime errors.

Specifically in your example, if A and B uses an incompatible interface, and A depends on B, then A will fail to resolve with a dependency error. So it won't even be able to start to pass it an incompatible type.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文