3

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

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.

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.

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

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

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 :))

Sample test project http://karaf.922171.n3.nabble.com/file/n4025256/KarafTest.zip

Note: this is cross-post from http://karaf.922171.n3.nabble.com/What-is-the-natural-start-order-for-dependent-bundle-td4025256.html

Xtra Coder
  • 3,389
  • 4
  • 40
  • 59
  • You said: "I expect order of the BundleActivator.start() to exactly correspond to package dependencies between bundles". Why do you have that expectation? It's incorrect, so I'm interested to know where it came from. – Neil Bartlett Jul 20 '12 at 11:02
  • Let's say this expectation comes from the "top of my head". I was thinking it should work this way. It appears to be wrong expectation after looking into OSGI specs. – Xtra Coder Jul 30 '12 at 11:22

1 Answers1

6

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

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.

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.

Flow
  • 23,572
  • 15
  • 99
  • 156
Christian Schneider
  • 19,420
  • 2
  • 39
  • 64
  • Thanks. I've looked into OSGI specs after your answer, and yes - specs do not specify start order in relation to package dependencies. However I've found another thing there - StartLevel. Each bundle has it from 0 (the framework itself) to MAX_INT. It appears that (at least with Felix & Karaf) that order depends on that StartLevel and it is possible to control it programmatically (via org.osgi.service.startlevel.StartLevel service). I've created small supplementary bundle to manage StartLevel for 'my' bundles as needed. – Xtra Coder Jul 30 '12 at 11:28
  • 2
    Never rely on start level for ordering. In OSGi any bundle can be updated/stopped/uninstalled at any time. Since this bypasses start levels, you can *never* rely that something is there unless you explicitly declare the dependency. – Peter Kriens Jul 22 '13 at 05:49