依赖包的 OSGI 包(在 Karaf 下)的自然启动顺序是什么? [英] What is the natural start order for package-dependent OSGI bundles (under Karaf)?

问题描述

我在 2.2.8 版本的 Karaf 上遇到了问题(很可能在早期版本上也是如此).

I have a problem on 2.2.8 version of Karaf (and most probably on the earlier versions too).

我将使用 Karaf 来托管带有动态部署包的系统.捆绑包由用户部署，我无法事先知道它们是哪些.

I'm going to use Karaf to host the system with dynamically deployed bundles. Bundles are deployed by users and i cannot know beforehand which are they.

我希望 BundleActivator.start() 的顺序与包之间的包依赖关系(导入/导出包的依赖关系)完全对应，并计划期望在 bundle1 开始之前假设 bundle0 将完全初始化是安全的开始.但事实并非如此 - BundleActivator.start() 似乎是以随机"顺序调用的，并且忽略了包之间的包依赖关系.

I expect order of the BundleActivator.start() to exactly correspond to package dependencies between bundles (dependencies of import/export packages) and planning to expect that it will be safe to assume that bundle0 will be completely initialized before bundle1 is going to be started. But it is not so - it seems that BundleActivator.start() is invoked in a "random" order and disregards package dependencies between bundles.

示例用例，我有 3 个库

Sample use-case, I have 3 libs

test-lib0 - defines testlib0.ITestRoot, exports testlib0 package 
test-lib1 - defines testlib1.TestRoot implements ITestRoot,  exports testlib1 package 
test-lib2 - uses both libs, ITestRoot and TestRoot 

当 Karaf 启动时，我在控制台中看到以下示例输出

When Karaf is started, i see following sample output in console

karaf@root> TestLib1Activator.start() 
TestLib2Activator.start() 
        ITestRoot: interface com.testorg.testlib0.ITestRoot - 16634462 
        TestRoot:  class com.testorg.testlib1.TestRoot - 21576551 
TestLib0Activator.start() 

但我希望它应该始终按此顺序

but i expect it should be always in this order

TestLib0Activator.start() 
TestLib1Activator.start() 
TestLib2Activator.start() 
        ITestRoot: interface com.testorg.testlib0.ITestRoot - 16634462 
        TestRoot:  class com.testorg.testlib1.TestRoot - 21576551 

我正在附上用于测试的示例项目.测试用例:在mvn install"之后，只需将 jars 从 ./deploy 文件夹移动到 Karaf 的同一文件夹中，跟踪消息应该出现在控制台中.(注意:它可能从第一次尝试就可以正常工作，然后再试一次:))

I'm attaching sample project for tests. Test case: after "mvn install" just move jars from ./deploy folder to the same folder of Karaf, trace messages should appear in console. (Note: it may work correctly from the first attempt, try one more time then :))

示例测试项目http://karaf.922171.n3.nabble.com/file/n4025256/KarafTest.zip

注意:这是来自 http://karaf.922171.n3.nabble.com/What-is-the-natural-start-order-for-dependent-bundle-td4025256.html

推荐答案

在 OSGi 中，bundle 生命周期是 installed →已解决 →开始 →开始.

In OSGi the bundle lifecycle is installed → resolved → starting → started.

Import-Package 和 Export-Package 仅在包从 installed 变为 resolved 时影响.因此，该框架确保您从中导入包的所有包都在您的包之前被解析，但您的包只会进入已解析状态.然后在第二步中调用激活器.所以你不能假设激活器是以相同的顺序调用的.如果您需要在 testlib2 工作之前进行一些初始化，那么您应该使用 OSGi 服务.

Import-Package and Export-Package only influence when the bundle goes from installed to resolved. So the framework makes sure all bundles you import packages from are resolved before your bundle but then your bundle only goes to the resolved state. Then in a second step the activators are called. So you can not assume the activators are called in the same order. If you need some initializations before your testlib2 can work then you should use OSGi services.

因此，如果我正确理解了您的情况，那么您 testlib0 定义了一个接口， testlib1 实现了它，而 testlib2 想要使用该实现.因此，实现这一点的最佳方法是在 testlib1 中将 impl 作为 OSGi 服务发布，并在 testlib3 中引用此服务.然后，您可以将服务与 ServiceTracker 或例如蓝图.我有一个小例子来说明这一点:http://www.liquid-reality.de/x/DIBZ .因此，如果您像我的示例蓝图那样处理您的案例，请确保 testlib2 的上下文仅在服务存在时启动.当服务消失时，它甚至会停止 testlib2.

So If I understood your case correctly then you testlib0 defines an interface, testlib1 implements it and testlib2 wants to use the implementation. So the best way to achieve this is to publish the impl as an OSGi service in testlib1 and reference this service in testlib3. You can then use the service with a ServiceTracker or with e.g. blueprint. I have a small example that shows this: http://www.liquid-reality.de/x/DIBZ . So if you do your case like in my example blueprint makes sure that the context of testlib2 only gets started when the service is there. It will even stop testlib2 when the service goes away.

这篇关于依赖包的 OSGI 包(在 Karaf 下)的自然启动顺序是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！