Modulare Enterprise-OSGi-Anwendungen mit Eclipse Gemini

Dependency Injection mit Blueprint

Eclipse Gemini Blueprint war die Blaupause für die Blueprint-Spezifikation und ist auch deren Referenzimplementierung. Damals hieß das Projekt noch Spring Dynamic Modules. SpringSource hat das Dynamic-Modules-Projekt an die Eclipse Foundation übergeben und dort wird es weitergeführt. Wer jedoch bereits Erfahrung mit Spring hat, für den ist die enge Verwandtschaft der Blueprint Services mit Spring unverkennbar.

Erste Schritte mit Gemini Blueprint

Dependency Injection ist ein Konfigurationsmechanismus und wird im Fall von Gemini Blueprint über xml-Dateien gesteuert. Sie werden im Verzeichnis META-INF/spring des OSGi Bundles erwartet. Alle xml-Dateien, die dort liegen, werden von Gemini Blueprint verarbeitet. Was können wir dort konfigurieren? Im Wesentlichen drei Dinge:

  1. Konsumierte Services
  2. Veröffentlichte Services
  3. Erzeugung von Beans

Listing 2 zeigt die Blueprint-Konfiguration aus dem UI Bundle ui.customer.view unserer Anwendung. Als Erstes wird der konsumierte Service CustomerRepository referenziert. Das ist in der XML-Konfiguration durch das Element reference ausgedrückt. Dort stehen das Interface des konsumierten Service und eine ID für die Referenz auf den konsumierten Service. Sie ist von Hand zu vergeben und muss innerhalb der Blueprint-Konfiguration des OSGi Bundles eindeutig sein. Das heißt, die ID customerRepository darf weder in dieser, noch in anderen XML-Konfigurationen innerhalb des Bundles erneut als ID verwendet werden.

Listing 2

Als Zweites wird in der Konfigurationsdatei im Element bean die Bean mit der ID tableView definiert. Hier wird im Attribut class die Java-Klasse mit der Implementierung der Bean angegeben. Gemini Blueprint erzeugt eine Instanz dieser Java-Klasse. Diese Instanz steht für sich und ist erstmal nicht mit OSGi Services verbunden. Um das zu tun, werden innerhalb des XML-Elements bean weitere Properties der Bean gesetzt. In unserem Beispiel referenziert die Bean tableView den Service customerRepository, wie im Element property innerhalb der Bean angegeben. So wird die Property customerRepository der tableView Bean die Referenz auf den Service customerRepository zugewiesen. Das Attribut name des Property-Elements gibt den Namen der Property an und das Attribut ref die ID einer anderen Bean oder eines Service. Zur Laufzeit wird auf der Klasse TableView der Setter setCustomerRepository aufgerufen, mit der konkreten Implementierung des CustomerRepository-Interface als Argument. Das ist Dependency Injection. Der Service customerRepository wird in die Instanz der Klasse TableView injected. Im Code der TableView-Klasse steht nur das Interface CustomerRepository, deren konkrete Instanz zur Laufzeit aufgelöst und injected wird.

In der dritten und letzten Zeile der Blueprint-Konfiguration wird ein OSGi Service veröffentlicht. Im XML-Element service steht im Attribut ref die ID der Bean mit dem Service, der veröffentlicht wird, sowie das Interface, das im Attribut interface veröffentlicht wird. In den nächsten Abschnitten werden wir diese drei wesentlichen Funktionen der Blueprint-Spezifikation noch detaillierter kennenlernen.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.