Kombination von OSGi-Blaupause und Federkonfiguration

Question

Gibt es gute/bewährte Methoden hinsichtlich der Kombination von Spring-Konfiguration und OSGi Blueprint (z. B. Gemini Blueprint)? Welche XML-Dateien verwenden Sie? Wo steckst du sie in deine OSGi-Bundles (, OSGi-INF)? Welche dieser Praktiken ermöglicht es Ihnen, Ihre Bundles in Kombination mit einer Nicht-Gemini-Implementierung von Blueprint wiederzuverwenden?

Hintergrund: Wir sind dabei, von Spring/Spring DM auf Spring/Blueprint umzustellen. Mir ist bekannt, dass Blueprint ein <bean> Element definiert. Gelegentlich sehen wir uns jedoch der Situation gegenüber, dass die eingeschränkten Definitionsfähigkeiten der Blueprint-Spezifikation nicht alle unsere Anforderungen erfüllen. Es scheint also eine gute Wahl zu sein, die Spring-Konfiguration in unseren Bundles und Blueprint für die Verkabelung von Paketen über OSGi-Dienste zu verwenden.

Answer 1

Blueprint-Dateien sollten unter OSGI-INF/Blueprint/laufen und heißen * .xml (normalerweise blueprint.xml). Dieser Speicherort entspricht der OSGi 4.2 Blueprint-Spezifikation und funktioniert mit Aries oder Gemini.

Frühlings-DM-Dateien (wie Sie wahrscheinlich wissen) gehen unter META-INF/Frühjahr/und auch * .xml (typischerweise beans.xml) genannt

Beide Dateien sollten friedlich koexistieren zu können. Sie funktionieren jedoch nur, wenn Sie Unterstützung für jeden installierten Container haben.

Die Verkabelung sollte über die OSGi Service Registry erfolgen.

Für die Migration sind wir auf Spring-DM für Funktionen geblieben, die wir in Blueprint nicht konnten. Alles andere wurde zu Blueprint migriert.

Answer 2

Welche XML-Dateien verwenden Sie? Wo steckst du sie in deine OSGi-Bundles (META-INF/spring, OSGi-INF)? Welche dieser Praktiken ermöglicht es Ihnen, Ihre Pakete in Kombination mit einer Nicht-Gemini-Implementierung von Blueprint zu verwenden?

Zwillinge Blueprint behandelt beiden Verzeichnisse gleich, aber OSGI-INF/blueprint/*.xml ist die einzige, in der generischen OSGi Blueprint-Spezifikation festgelegt.

Eine vorgeschlagene Praxis von the Gemini Blueprint documentation ist:

[...] Ein vorgeschlagen Praxis ist die Anwendung Kontextkonfiguration in mindestens zwei Dateien, genannt vereinbarungsmodul-context.xml aufzuspalten und modulename-osgi-context.xml. Die Datei modulename-context.xml enthält reguläre Bean-Definitionen unabhängig von OSGi-Kenntnissen von . Die Datei modulename-osgi-context.xml enthält die Bean Definitionen zum Importieren und Exportieren von OSGi-Diensten. Es kann (aber ist nicht erforderlich) das Gemini Blueprint OSGi-Schema als den -Namespace der obersten Ebene anstelle des Spring-Beans-Namespaces verwenden.

Ich habe das versucht, und es funktioniert super. Ich verwende Gemini Blueprint für eines meiner Projekte, das die Dateien META-INF/spring/context.xml enthält, in dem meine Beans und ihre Beziehungen definiert sind, und META-INF/spring/osgi-context.xml, in dem definiert wird, welche Beans als OSGi-Services und wie importiert werden sollen.context.xml sieht aus wie

<beans xmlns="http://www.springframework.org/schema/beans" 
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
     xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd"> 
    <bean id="myOrdinarySpringBean" class="com.acme.impl.Foo"/> 
</beans> 

und ist ein regelmäßiger gewöhnlicher Spring-Anwendungskontext ohne Blueprint/OSGi-Konfiguration überhaupt. osgi-context.xml sieht aus wie

<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"> 
    <service id="myOsgiService" ref="myOrdinarySpringBean" interface="com.acme.Foo"/> 
</blueprint> 

Sie könnten natürlich, verwenden Sie das <beans> Namespace und Wurzelelement auch hier, aber Sie würden ein xmlns:osgi und Präfix den Dienst wie so definieren müssen: <osgi:service .../> dafür zu arbeiten. In meinem Fall benötige ich kein Gemini-spezifisches Blueprint-Zeug, daher bin ich mit dieser allgemeinen Blueprint-Konfiguration zufrieden. Ebenso könnte ich auch den <blueprint> Namespace in context.xml verwenden, aber diese spezielle Anwendung ist eine alte, die nach OSGi portiert wurde, daher bevorzuge ich, diese Konfiguration Spring spezifisch für jetzt zu behalten.

Eine weitere Anwendung wiederum hat seine eigene osgi-context.xml wie

<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"> 
    <reference id="myOrdinarySpringBeanImportedFromOsgi" interface="com.acme.Foo" availability="mandatory"/> 
</blueprint> 

und zu diesem Zeitpunkt nicht, aber konnte, haben ihre eigene context.xml wie

<beans xmlns="http://www.springframework.org/schema/beans" 
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
     xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd"> 
    <bean id="myOrdinaryOtherSpringBean" class="com.acme.impl.Bar"> 
     <property name="foo" ref="myOrdinarySpringBeanImportedFromOsgi"/> 
    </bean> 
</beans> 

und konnte nicht wirklich wurscht ob myOrdinarySpringBeanImportedFromOsgi aus einem OSGi-Service importiert oder als regulärer Spring-Bean im selben Anwendungskontext definiert wird.

Diese META-INF/osgi-context.xml Konfigurationen könnten trivialerweise zu OSGI-INF/blueprint/ verschoben werden, wenn ich mich von der Gemini Blueprint-Implementierung entkoppeln möchte, aber vorläufig bevorzuge ich die beiden Hälften an der gleichen Stelle zu halten, um ein Durcheinander der Verzeichnisstruktur zu vermeiden .