2016-08-07 4 views
0

Die Frage ist einfach, aber ich kann keine Antwort finden - Kann ich feststellen, dass alle deklarativen Dienste in Bündel A nach Bündel A Start verfügbar sind? Zum BeispielOSGI: werden deklarative Dienste nach dem Start des Pakets verfügbar

bundle=context.installBundle("file:bundleA-1.0.0.jar"); 
bundle.start(); 
//In this point are declarative services of bundle A 100% available? 

P.S. Ich benutze Apache Felix, aber ich denke, es muss in Specs definiert werden, aber nicht in der Umsetzung.

EDIT:
Ich gehe davon aus, dass DS Laufzeit ausgeführt wird, Config vorhanden ist und alle Pflicht Referenzen vorhanden sind.

+0

Diejenigen viele Annahmen sind, die Sie wirklich sind in keiner Position zu machen. –

Antwort

2

Die Antwort auf Ihre Frage ist sehr einfach: NEIN. Es gibt KEINE Garantien für die Verfügbarkeit in OSGi, weder auf der Grundlage des Timings noch der Bestellung. Die einzigen Garantien sind in den Service-Ereignissen angegeben.

Es ist eine der größten Ursachen für Komplexität, Timing-/Ordnungsannahmen in Ihrem Code zu treffen, weil sie immer auf die dunkelste Art und Weise verletzt werden.

DS macht es trivial, Code zu schreiben, der korrekt auf die Dienstabhängigkeiten reagiert, wenn sie kommen und gehen. Sicherzustellen, dass Sie diese mit den Diensten verbundenen Garantien erhalten, ist unglaublich komplex und Sie zerstören diesen ganzen Wert, wenn Sie anfangen, Annahmen zu machen, dass nach dem Aufruf einer Methode verfügbar sein sollte.

In Ihrem Beispiel, verlassen Sie sich einfach auf einen Service, den Sie brauchen. Wenn dieser Dienst verfügbar ist, sind Sie sicher, dass die Initialisierung abgeschlossen ist.

Wenn Sie sich an Serviceabhängigkeiten halten, ist die Lebensdauer in OSGi ziemlich einfach und sehr robust.

mit Beispiel AKTUALISIERT nach Fragen

Einer der nicht-OSGi Seite:

systemBundleContext = ... create framework 
systemBundleContext.registerService( 
    BundleActivator.class, 
    new BundleActivator() { 
     public void start(BundleContext c) { 
      // start non-OSGi code 
     } 
     public void stop(BundleContext c) { 
      // stop non-OSGi code 
     } 
    }, 
    null); 

DS Komponente:

@Component 
public class Initiator { 
    @Reference 
    BundleActivator ba; 

    @Referenc 
    MyService myService; 

    @Activate void activate(BundleContext context) throws Exception { 
     ba.start(context); 
    } 

    @Deactivate void deactivate(BundleContext context) throws Exception { 
     ba.stop(context); 
    } 
}  
+0

Nehmen wir an, ich habe nur einen deklarativen Dienst - Dienst A. Und ich muss diesen Dienst in gewöhnlichem Code verwenden, nicht in einem anderen osgi-Dienst. Also verstehe ich Sie richtig - dass der einzige Weg ist, Service Tracker in einer solchen Situation zu verwenden? –

+0

ServiceTracker könnte funktionieren, aber es gibt eine viel einfachere Lösung.Das Problem ist eine der ** Kontrolle ** (die ich als eine der interessantesten am wenigsten diskutierten Aspekte des Schreibens von Code betrachte). Wahrscheinlich würde ich einen BundleActivator-Dienst auf der Nicht-OSGi-Seite registrieren und dann eine direkte DS-Komponente auf der OSGi-Seite mit den entsprechenden Abhängigkeiten erstellen. Diese Komponente ruft den Framework-Seiten-Service beim Aktivieren/Deaktivieren auf. Auf diese Weise haben Sie die Kontrolle auf der DS-Seite und die Nicht-OSGi-Seite folgt ihr. –

+0

Ich lese dich mehrmals kommentieren .. aber .. könntest du im Code angeben, was du meinst? –

0

Sie können nicht davon ausgehen, dass alle DS-Komponenten nach dem Start des Bundles als Dienste verfügbar sind. Die erste Sache ist, dass die DS-Runtime auch ausgeführt werden muss. Dann sind DS-Komponenten standardmäßig nicht aktiviert. Dies bedeutet, dass sie nur dann aktiv sind, wenn ein anderes Paket einen solchen Dienst benötigt und nicht zuletzt Komponenten erst dann aktiviert werden, wenn alle obligatorischen Referenzen vorhanden sind. Nun ... und bevor ich es vergesse kann man auch definieren, dass eine Komponente nur aktiviert wird, wenn eine Config dafür vorhanden ist.

+0

Bitte, siehe meine Bearbeitung. –

+0

In diesem Fall bleibt nur das träge Laden als Ursache übrig. Verwenden Sie sofort = wahr? –

+0

Ich denke, es gibt einen Unterschied zwischen verfügbarem Service und Service mit erstellter Instanz. Wenn ich verfügbar sage, meine ich, dass, wenn dieser Dienst notwendig ist, das OSGI-Framework seine Instanzen erstellen wird. –

Verwandte Themen