依赖于软件包的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()的顺序与包之间的包依赖关系(导入/导出包的依赖关系)完全对应，并计划期望可以安全地假设bundle0将在bundle1进行之前完全初始化开始.但事实并非如此-似乎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个库

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

注意:这是来自推荐答案

在OSGi中，捆绑软件生命周期为installed→. resolved→ starting→ started.

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想使用该实现.因此，实现此目的的最佳方法是将impl在testlib1中发布为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屋！