Angepasste Blueprint-Namespace-Handler

Die Blueprint-Container-Spezifikation, die in Release 5 der OSGi-Enterprise-Spezifikation eingeführt wurde, stellt ein einfaches und komfortables Programmiermodell für die Erstellung dynamischer Anwendungen in der OSGi-Umgebung vor, ohne die Komplexität des Java™-Codes zu steigern.

Weitere Informationen zum Release der OSGi-Enterprise-Spezifikation finden Sie unter OSGi specification download.

In der Blueprint-Container-Spezifikation ist ein Dependency-Injection-Framework für OSGi definiert, das für die Handhabung der dynamischen Natur von OSGi, bei der jederzeit Services verfügbar und nicht verfügbar sein können, konzipiert wurde. Bei der Konzeption der Spezifikation wurde auch berücksichtigt, dass sie mit POJOs (Plain Old Java Objects) funktionieren können soll, damit innerhalb und außerhalb des OSGi-Frameworks dieselben Objekte verwendet werden können. Die Blueprint-XML-Dateien, die die verschiedenen Komponenten einer Anwendung definieren und beschreiben, sind der wichtigste Teil des Blueprint-Programmiermodells. In der Spezifikation ist beschrieben, wie die Komponenten instanziiert und per Wire verbunden werden, um zusammen eine aktive Anwendung bilden zu können. Weitere Informationen finden Sie in den Informatinoen zur OSGi Blueprint-Container-Spezifikation in der WebSphere Developer Tools-Dokumentation.

Jedes Blueprint-Bundle muss eine Blueprint-XML-Datei enthalten, damit die Blueprint-Laufzeit die Blueprint-Komponente des Bundles verarbeiten kann. Das Standard-Blueprint-Element ist in der OSGi-Blueprint-Spezifikation definiert und muss in jedem Blueprint-XML-Dokument enthalten sein. Es legt den Standarddokument-Namespace auf http://www.osgi.org/xmlns/blueprint/v1.0.0. Beispiel:
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
Nach Standard-XML-Regeln können andere Namespaces als Einträge mit Präfix oder direkt in den angepassten XML-Elementen zum Blueprint-Dokument hinzugefügt werden. Diese Namespaces können auf der Ausgangsebene oder in die angepassten XML-Elemente integriert hinzugefügt werden. Solange es sich um gültige XML handelt, kann eine ordnungsgemäße Auswertung erfolgen. Beispiel für eine Definition im Blueprint-Element der Ausgangsebene:
<blueprint 
  xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
  xmlns:tx="http://aries.apache.org/xmlns/transactions/v1.0.0">
Beispiel für eine in ein angepasstes Element integrierte Definition:
<transaction method="*" value="Required"
  xmlns:tx="http://aries.apache.org/xmlns/transactions/v1.0.0"/>

Die vom Apache-Aries-Projekt bereitgestellte Blueprint-Laufzeitimplementierung wird zur Unterstützung von Blueprint-Bundles verwendet, die in OSGi-Anwendungen für Liberty enthalten sind. Weitere Informationen finden Sie unter Apache Aries. Die Aries-Blueprint-Laufzeit stellt einen Erweiterungsmechanismus mit der Bezeichnung Namespace-Handler bereit. Ein Namespace-Handler ist ein Prozessor für angepasste Blueprint-Erweiterungen oder -Namespaces. Er implementiert die Schnittstelle org.apache.aries.blueprint.NamespaceHandler und muss mit einer zugehörigen Serviceeigenschaft osgi.service.blueprint.namespace in der OSGi-Serviceregistry registriert werden. Diese Eigenschaft bezeichnet die Namespace-URIs, die dieser Handler verarbeiten kann, z. B. http://aries.apache.org/xmlns/transactions/v1.0.0. Der Wert der Serviceeigenschaft kann eine einzelne Zeichenfolge (String) oder URI oder eine Sammlung (Collection) bzw. ein Array mit Zeichenfolgen oder URIs sein.

Die Blueprint-Laufzeit analysiert die Blueprint-Deskriptoren zweimal. Beim ersten schnellen Durchgang werden nur Namespaces gefunden, die vom Blueprint-Bundle verwendet werden. Wenn das Blueprint-Bundle einen vom Standard abweichenden Namespace verwendet, versucht der Blueprint-Container, für jeden angepassten Namespace NamespaceHandler-Services in der OSGi-Serviceregistry zu finden. Ein NamespaceHandler-Service macht jeden XML-Namespace, den er verarbeiten kann, über OSGi-Serviceeigenschaften zugänglich. Die Blueprint-Laufzeit analysiert die Blueprint-XML erst, wenn für jeden im Bundle verwendeten angepassten Namespace ein NamespaceHandler-Service gefunden wurde. Bis NamespaceHandler-Services für alle angepassten Namespaces gefunden wurden, kann der Blueprint-Container das Bundle nicht verarbeiten. Existiert kein NamespaceHandler, kann dies bedeuten, dass der Blueprint-Container unendlich lange wartet. Sollte diese Situation eintreten, setzt der Blueprint-Container eine Warnung im Protokoll ab. Wenn der Blueprint-Parser mit der Auswertung der Blueprint-XML-Dateien beginnt, analysiert er alle Standard-Blueprint-Elemente. Sobald der Parser ein angepasstes Element erreicht, informiert er den NamespaceHandler, der Unterstützung für den Namespace des angepassten Elements zugänglich macht. Der NamespaceHandler hat hier die Gelegenheit, die Informationen in dem angepassten Element zu verarbeiten, das Laufzeit-Blueprint-Modell zu modifizieren oder eine andere Operation auszuführen. Wenn eine Namespacedefinition einen Tippfehler enthält, kann das Blueprint-Dokument höchstwahrscheinlich nicht gestartet werden.

Ein angepasster NamespaceHandler-Service kann von jedem in Liberty ausgeführten Bundle, einschließlich der Liberty-Feature-Bundles und der OSGI-Application-Bundles, bereitgestellt werden.


Symbol das den Typ des Artikels anzeigt. Referenzartikel



Symbol für Zeitmarke Letzte Aktualisierung: 01.12.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rwlp_blueprint_namespace_handler
Dateiname: rwlp_blueprint_namespace_handler.html