Blueprint-XML

Eine Blueprint-XML-Datei wird mit einem Ausgangselement "blueprint" identifiziert und enthält Definitionen von Komponentenmanagern wie Bean-Managern, Servicemanagern und Service-Reference-Managern.

Eine Blueprint-XML-Datei wird, wie im folgenden Beispielcode aus einer Datei blueprint.xml gezeigt, über ein Ausgangselement "blueprint" identifiziert.

<?xml version="1.0" encoding="UTF-8"?> 
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
   ... 
</blueprint>

Der XML-Namespace gibt an, dass das Dokument Blueprint Version 1.0.0 entspricht. Das Ausgangselement "Blueprint" identifiziert das Dokument als Blueprint-Moduldefinition.

Die Blueprint-XML-Datei enthält Definitionen verschiedener Komponentenmanager. Die Blueprint-Container-Spezifikation definiert vier Hauptkomponentenmanager:
  • Ein Bean-Manager erstellt eine Instanz eines Java™ -Objekts mit den angegebenen Argumenten und Eigenschaften. Ein Bean-Manager kann je nach Geltungsbereichseinstellungen eine einzige oder mehrere Objektinstanzen erstellen. Außerdem kann er den Lebenszyklus eines Objekts verwalten und das Objekt benachrichtigen, wenn alle Eigenschaften injiziert wurden oder wenn das Objekt gelöscht wird.
  • Ein Servicemanager registriert einen Service in der OSGi-Service-Registry und nimmt dessen Registrierung zurück.
  • Zwei Service-Reference-Manager ermöglichen den Zugriff auf den in der OSGi-Service-Registry registrierten Service:
    • Ein Reference-Manager stellt ein Objekt bereit, das ein Proxy für den in der Service-Registry definierten Service ist.
    • Ein Reference-List-Manager stellt eine dynamische Liste mit Service-Proxy-Objekten oder Service-Reference-Objekten bereit, die derzeit in der Service-Registry enthalten sind.
Jeder Komponentenmanager erstellt Komponenten und verwaltet den Lebenszyklus dieser Komponenten. Auf Anforderung stellen die Manager eine Komponenteninstanz bereit. Jeder Manager hat ein entsprechendes XML-Element, das die Managereigenschaften beschreibt. Die Manager können Ausgangsmanager oder in anderen Managerdefinitionen als integrierte Deklaration definiert sein. Alle Komponentenmanager können die folgenden Attribute haben:
ID
Dieses optionale Attribut definiert die ID eines Ausgangsmanagers. Die ID muss für alle Ausgangsmanager im Blueprint-Container eindeutig sein. Wenn Sie dieses Attribut nicht angeben, wird automatisch eine eindeutige ID generiert. Manager verwenden die ID, um einander zu referenzieren. Während der Injektion fordert der Manager die referenzierten Manager beispielsweise auf, ein Objekt bereitzustellen, das in die Komponente injiziert wird, die der Manager erstellt.

Definieren Sie das Attribut "id" nicht für Manager, die in anderen Managerdefinitionen als integrierte Deklaration definiert sind, da diese Manager als anonym eingestuft werden.

activation
Dieses optionale Attribut definiert den Aktivierungsmodus des Managers. Die folgenden Aktivierungsmodi werden unterstützt:
  • Eager (vorsorglich). Der Manager wird während der Initialisierung des Blueprint-Containers aktiviert. Dies ist die Standardeinstellung.

    Ein Servicemanager wird in der Service-Registry veröffentlicht und aktiviert den Bean-Manager, der dem Service zugrunde liegt.

  • Lazy (verzögert). Der Manager wird auf Anforderung gestartet. Ein Manager wird aktiviert, wenn er aufgefordert wird, seine erste Komponenteninstanz bereitzustellen.

    Bei einem Bean-Manager wird die Bean nur initialisiert, wenn ein anderer Bean-Manager auf ihn zugreift. Ein Servicemanager wird in der Service-Registry veröffentlicht, aktiviert aber nicht den Bean-Manager, der dem Service zugrunde liegt.

Wenn Sie den Standardaktivierungsmodus für alle Manager in der Blueprint-XML-Datei ändern möchten, setzen Sie das Attribut "default-activation" im Element "Blueprint".

Jeder Manager hat eigene Aktivierungs- und Inaktivierungsschritte. Ein Manager wird inaktiviert, wenn der Blueprint-Container gelöscht wird.

dependsOn
Dieses optionale Attribut definiert die expliziten Abhängigkeiten eines Managers. Es gibt eine Liste mit Manager-IDs an, bei denen diese Manager aktiviert werden müssen, bevor dieser Manager aktiviert wird. Ein Manager kann auch implizite Abhängigkeiten haben, die durch Referenz auf andere Manager in einer Managerdefinition definiert werden.