2012-04-02 3 views
2

Ich Tracking OSGi-Bundles wie folgt aus:OSGi BundleTracker: Reihenfolge der Kettenbündel

BundleTracker<Foo> bundleTracker = new BundleTracker<>(context, Bundle.ACTIVE, 
    new BundleTrackerCustomizer<Foo>(){ 

       @Override 
       public Foo addingBundle(Bundle bundle, BundleEvent event) { 
        ... 
       } 

       @Override 
       public void modifiedBundle(Bundle bundle, BundleEvent event, Foo foo) { 
        ... 
       } 

       @Override 
       public void removedBundle(Bundle bundle, BundleEvent event, Foo foo) { 
        ... 
       } 
      }); 

Nun, wenn ein Bündel B eine Abhängigkeit A und B gestartet wird, dann als ich das erste Bündel A verstehen wird aktiviert. Ist das richtig?

Das Problem ist, dass ich manchmal über einige Bundles benachrichtigt werde, bevor ich über ihre abhängigen Bundles benachrichtigt werde. Also, wie kann ich in Abhängigkeitsreihenfolge benachrichtigt werden (wenn B von A abhängt, dann werde ich zuerst über A und dann über B informiert)?

Antwort

3

Codeabhängigkeiten (Importpaket oder requiry bundle) zwischen Bündeln haben (im Allgemeinen) keinen Einfluss auf die Startfolge von Bündeln. Dies ist eine Interaktion zwischen Bündeln, die eine verzögerte Aktivierung verwenden.

Also, wenn A und B gelöst sind, auf keinen Einfluss hat B beginnen A. Start

Wichtig ist hierbei zu beachten ist, dass die Modulschicht Abhängigkeiten nicht die Startreihenfolge der Pakete beeinflussen.

+0

Aber wenn B-Klassen von A verwendet, dies bedeutet nicht, dass A vor B aktiviert werden? – Puce

+0

@Puce Nein, das heißt überhaupt nicht. Bj's Antwort macht das sehr deutlich. –

+0

Wäre es möglich, dass das Bündel A immer vor dem Bündel B aufgelöst wird? Wenn dies der Fall ist und Sie unbedingt die Benachrichtigungen in Abhängigkeitsreihenfolge abrufen müssen, können Sie nach den Ereignissen von Bundle.RESOLVED Ausschau halten, die Bestellung aufzeichnen und dies berücksichtigen, wenn Sie die Bundle.ACTIVATED-Ereignisse erhalten. –

2

Codeabhängigkeiten haben keinen Einfluss auf die Aktivierung, da alle Bündel atomar aufgelöst werden. Wenn also ein Bündel aktiviert wird, ist es sicher, dass es nur auf gelöste Bündel ankommt. OSGi hat eine Modulschicht (mit Paketabhängigkeiten) und eine Serviceschicht. Die Modulebene ist statisch und die Serviceschicht ermöglicht es Ihnen, dynamische Abhängigkeiten (mit DS) auszudrücken.

Wenn Sie mit Start um zu kämpfen haben, die Sie wahrscheinlich tun es nicht richtig ...

+0

Nun, ja, ich habe jetzt gelesen, dass Best Practices vorschreiben, dass man sich nicht auf die Aktivierungsreihenfolge verlassen sollte. Die Sache ist, dass ich ein Erweiterungs-Framework auf Basis des Extender-Pattern, JAXB und Services (einige davon dynamisch) implementiere: Bundle A spezifiziert eine Erweiterungspunkt-Schnittstelle, wo Erweiterungspunkte ihre JAXB-Stammklasse zurückgeben müssen. Bundles, die Erweiterungspunkte definieren, spezifizieren ihre JAXB-Klassen und registrieren ihre Erweiterungspunkt-Implementierung unter Verwendung von DS. Bundle A überwacht diese Erweiterungspunkte mithilfe von DS. Es verfolgt auch Bundles und prüft, ob sie eine XML-Erweiterungsdatei haben. – Puce

+0

Wenn ein Bundle eine XML-Erweiterungsdatei enthält, wird es mithilfe der JAXB-Stammklassen, die von den registrierten Erweiterungspunkten angegeben werden, entpackt. Wenn ein Bündel Y eine Erweiterungs-XML für einen durch Bündel X definierten Erweiterungspunkt angibt, deklariert Y auch eine Abhängigkeit von X (weil es Annotationen, Annotationsprozessor und JAXB-Klassen verwendet, die von Y zum Erstellen der XML-Erweiterungsdatei bereitgestellt werden). – Puce

+0

Nun meine Annahme war, seit X (mit einer Erweiterung XML-Datei) hat eine Abhängigkeit von Y (Angabe des Erweiterungspunkts und der JAXB-Klassen erforderlich zum Unmarshall der Erweiterung XML-Datei von X), Y wird vor X aktiviert werden. Aber der BundleTracker manchmal erkennt über Bündel in einer anderen Reihenfolge. – Puce