Combinare il progetto di OSGi e la configurazione della molla

Question

Esistono buone/migliori pratiche relative alla combinazione di configurazione Spring e Progetto OSGi (ad esempio Gemini Blueprint)? Quali file XML usi? Dove li metti nei tuoi bundle OSGi (META-INF/spring, OSGi-INF)? Quale di queste pratiche ti consentirà di riutilizzare i tuoi bundle in combinazione con un'implementazione non-Gemini di Blueprint?

Background: Stiamo passando da Spring/Spring DM a Spring/Blueprint. Sono a conoscenza di Blueprint che definisce un elemento <bean>. Tuttavia, occasionalmente ci troviamo di fronte alla situazione in cui le capacità di definizione dei bean limit della specifica Blueprint non soddisfano tutte le nostre esigenze. Pertanto, sembra essere una buona scelta utilizzare la configurazione Spring nei nostri bundle e Blueprint per il cablaggio di bundle tramite i servizi OSGi.

Answer 1

I file di progetto devono passare sotto OSGI-INF/blueprint/e sono denominati * .xml (in genere blueprint.xml). Questa posizione è conforme alle specifiche Blueprint OSGi 4.2 e funzionerà con Ariete o Gemini.

file Primavera-DM (come probabilmente sapete) vanno sotto META-INF/primavera/e sono anche chiamati * .xml (tipicamente beans.xml)

Entrambi i file devono essere in grado di coesistere pacificamente. Funzioneranno solo, tuttavia, se si dispone del supporto per ciascun contenitore installato.

Il cablaggio deve essere eseguito tramite il registro del servizio OSGi.

Per quanto riguarda la migrazione, siamo rimasti su Spring-DM per le funzionalità che non potevamo fare in Blueprint. Tutto il resto è stato migrato su Blueprint.

Answer 2

Quali file XML utilizzate? Dove li metti nei tuoi bundle OSGi (META-INF/spring, OSGi-INF)? Quale di queste pratiche ti consente di riutilizzare i tuoi bundle in combinazione con un'implementazione non Gemini di Blueprint?

Blueprint Gemini tratta entrambe queste directory ugualmente, ma OSGI-INF/blueprint/*.xml è l'unico specificato nella specifica OSGi Blueprint generico.

Un suggerito pratica da the Gemini Blueprint documentation è:

[...] A suggerito la pratica è quella di dividere la configurazione contesto applicativo in almeno due file, di nome per convenzione modulename-context.xml e modulename-osgi-context.xml. Il file modulename-context.xml contiene definizioni di bean regolari indipendenti da qualsiasi conoscenza di OSGi. Il file modulename-osgi-context.xml contiene le definizioni del bean per l'importazione e l'esportazione dei servizi OSGi. Può (ma non è richiesto a ) utilizzare lo schema OSGi di Gemini Blueprint come lo spazio dei nomi di livello superiore invece dello spazio dei nomi "bean" di Spring.

Ho provato questo, e funziona benissimo. Uso Gemini Blueprint per uno dei miei progetti che contiene i file META-INF/spring/context.xml, che definisce i miei bean e le loro relazioni, e META-INF/spring/osgi-context.xml, che definisce quali bean esporre come/import da servizi OSGi e come.context.xml sembra

<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> 

ed è un contesto di applicazione della molla ordinaria regolare senza alcuna configurazione Blueprint/OSGi a tutti. osgi-context.xml sembra

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

Si potrebbe, ovviamente, usare l'elemento <beans> spazio dei nomi e la radice anche qui, ma che avrebbe dovuto definire una xmlns:osgi e prefisso il servizio in questo modo: <osgi:service .../> per questo al lavoro. Nel mio caso non ho bisogno delle specifiche Blueprint di Gemini, quindi sono soddisfatto di questa configurazione generica di Blueprint. Allo stesso modo, potrei usare lo spazio dei nomi <blueprint> in context.xml, ma questa particolare applicazione è una vecchia porta su OSGi, quindi preferisco mantenere quella configurazione specifica per ora.

Un'altra applicazione a sua volta ha il suo osgi-context.xml come

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

e in questo momento non lo fa, ma poteva, hanno un proprio context.xml come

<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> 

e non potrebbe davvero fregare di meno se myOrdinarySpringBeanImportedFromOsgi viene importato da un servizio OSGi o definito come normale bean Spring ordinario nello stesso contesto applicativo.

Questi META-INF/osgi-context.xml configurazioni potrebbero banalmente essere spostati in OSGI-INF/blueprint/ se voglio separare se stessi dal implementazione Blueprint Gemini, ma per il momento preferisco mantenere le due metà nello stesso luogo per evitare di fare un pasticcio della struttura di directory .