Was ist die natürliche Startreihenfolge für paketabhängige OSGI-Bundles (unter Karaf)?

Question

Ich habe ein Problem mit der Version 2.2.8 von Karaf (und höchstwahrscheinlich auch mit den früheren Versionen).

Ich werde Karaf verwenden, um das System mit dynamisch bereitgestellten Paketen zu hosten. Bundles werden von Benutzern bereitgestellt und ich kann nicht im Voraus wissen, welche sie sind.

Ich erwarte, dass die Reihenfolge von BundleActivator.start() genau den Paketabhängigkeiten zwischen den Bundles entspricht (Abhängigkeiten von Import-/Exportpaketen) und dass man davon ausgehen kann, dass Bundle0 vollständig initialisiert wird, bevor Bundle1 gestartet wird. Dem ist aber nicht so - es scheint, dass BundleActivator.start() in einer "zufälligen" Reihenfolge aufgerufen wird und Paketabhängigkeiten zwischen Bundles außer Acht lässt.

Beispiel für einen Anwendungsfall, ich habe 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 

Wenn Karaf gestartet wird, sehe ich in der Konsole folgende Beispielausgabe

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

aber ich erwarte, dass es immer in dieser Reihenfolge sein sollte

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

Ich füge ein Beispielprojekt für Tests bei. Testfall: nach "mvn install" einfach jars aus dem Ordner ./deploy in den gleichen Ordner von Karaf verschieben, Trace-Meldungen sollten in der Konsole erscheinen. (Hinweis: Es kann sein, dass es beim ersten Versuch richtig funktioniert, versuchen Sie es dann noch einmal :))

Beispielhaftes Testprojekt http://karaf.922171.n3.nabble.com/file/n4025256/KarafTest.zip

Hinweis: Dies ist ein Cross-Post von http://karaf.922171.n3.nabble.com/What-is-the-natural-start-order-for-dependent-bundle-td4025256.html

Answer 1

In OSGi ist der Bundle-Lebenszyklus installed → resolved → starting → started .

Import-Package und Export-Package wirken sich nur aus, wenn das Bündel von installed a resolved . Das Framework stellt also sicher, dass alle Bundles, aus denen Sie Pakete importieren, vor Ihrem Bundle aufgelöst werden, aber dann geht Ihr Bundle nur in den aufgelösten Zustand. In einem zweiten Schritt werden dann die Aktivatoren aufgerufen. Sie können also nicht davon ausgehen, dass die Aktivatoren in der gleichen Reihenfolge aufgerufen werden. Wenn Sie einige Initialisierungen benötigen, bevor Ihre testlib2 funktionieren kann, sollten Sie OSGi-Dienste verwenden.

Wenn ich also Ihren Fall richtig verstanden habe, dann definiert testlib0 eine Schnittstelle, testlib1 implementiert sie und testlib2 möchte die Implementierung verwenden. Der beste Weg, dies zu erreichen, ist also, das Impl als OSGi Service in testlib1 zu veröffentlichen und diesen Service in testlib3 zu referenzieren. Sie können dann den Service mit einem ServiceTracker oder z.B. mit einem Blueprint verwenden. Ich habe ein kleines Beispiel, das dies zeigt: http://www.liquid-reality.de/x/DIBZ . Wenn Sie also Ihren Fall wie in meinem Beispiel ausführen, sorgt Blueprint dafür, dass der Kontext von testlib2 nur gestartet wird, wenn der Dienst vorhanden ist. Es wird sogar testlib2 stoppen, wenn der Dienst verschwindet.