Połączyć schemat OSGi i konfigurację sprężyny

Question

Czy istnieją jakieś dobre/najlepsze praktyki dotyczące kombinacji konfiguracji sprężyn i schematu OSGi (np. Gemini Blueprint)? Z jakich plików XML korzystasz? Gdzie umieszczasz je w swoich pakietach OSGi (META-INF/spring, OSGi-INF)? Która z tych metod pozwoli Ci ponownie wykorzystać pakiety w połączeniu z implementacją Blueprint bez Gemini?

Tło: Jesteśmy w trakcie przełączania z Spring/Spring DM na Spring/Blueprint. Mam świadomość, że Blueprint definiuje element <bean>. Czasami jednak stajemy przed sytuacją, że ograniczone możliwości definicji fasoli według specyfikacji Blueprint nie spełniają wszystkich naszych potrzeb. Tak więc wydaje się dobrym wyborem, aby używać konfiguracji Spring w naszych pakietach i Blueprint do łączenia wiązek za pośrednictwem usług OSGi.

Answer 1

Pliki w postaci planów powinny być zgodne z OSGI-INF/blueprint/i mają nazwę * .xml (zazwyczaj blueprint.xml). Ta lokalizacja jest zgodna ze specyfikacją OSGi 4.2 Blueprint i będzie działać z Aries lub Gemini.

pliki Wiosna-DM (jak zapewne wiesz) iść pod META-INF/wiosna/i są również nazywane * .xml (zazwyczaj beans.xml)

Oba pliki powinny być w stanie pokojowo współistnieć. Będą działać tylko, jeśli masz wsparcie dla każdego zainstalowanego kontenera.

Okablowanie należy wykonać za pośrednictwem rejestru usług OSGi.

Jeśli chodzi o migrację, zostaliśmy na Spring-DM z powodu możliwości, których nie mogliśmy zrobić w Blueprint. Cała reszta została przeniesiona do Blueprint.

Answer 2

Z jakich plików XML korzystasz? Gdzie umieszczasz je w swoich pakietach OSGi (META-INF/wiosna, OSGi-INF)? Która z tych metod pozwoli Ci ponownie wykorzystać pakiety w połączeniu z implementacją inną niż Gemini Blueprint?

Gemini Blueprint traktuje obu tych katalogach równo, ale OSGI-INF/blueprint/*.xml jest tylko jeden określony w ogólnej specyfikacji OSGi Blueprint.

Sugerowany praktyki z the Gemini Blueprint documentation jest:

[...] zasugerował praktyką jest podzielona konfigurację kontekstowego aplikacji na co najmniej dwóch plików, nazwany przez konferencyjnym modulename-context.xml i modulename-osgi-context.xml. Plik modulename-context.xml zawiera zwykłe definicje fasoli niezależne od wiedzy o OSGi . Plik modulename-osgi-context.xml zawiera definicje fasoli do importowania i eksportowania usług OSGi. Może (ale nie jest wymagane) używanie schematu Gemini Blueprint OSGi jako przestrzeni nazw najwyższego poziomu zamiast obszaru nazw Spring 'beans'.

Próbowałem tego i działa świetnie. Używam Gemini Blueprint do jednego z moich projektów, który ma pliki META-INF/spring/context.xml, które definiują moje fasolki i ich relacje, oraz META-INF/spring/osgi-context.xml, który określa, które ziarno eksponować jako/importować z usług OSGi i jak.context.xml wygląda

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

i jest regularnym zwykły kontekst aplikacji Wiosna bez konfiguracji Blueprint/OSGi w ogóle. osgi-context.xml wygląda

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

Można by oczywiście użyć elementu <beans> namespace i korzeń tutaj jak dobrze, ale trzeba by zdefiniować xmlns:osgi i prefiks usługę tak: <osgi:service .../> za to do pracy. W moim przypadku nie potrzebuję rzeczy specyficznych dla Gemini, więc cieszę się z tej ogólnej konfiguracji Blueprint. Podobnie mógłbym używać przestrzeni nazw <blueprint> również w context.xml, ale ta konkretna aplikacja jest starą, która jest przeniesiona do OSGi, więc wolę zachować tę konfigurację Spring specyficzną dla teraz.

Inna aplikacja z kolei posiada własny osgi-context.xml jak

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

i w tej chwili nie, ale mogłaby mieć własną context.xml jak

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

i nie troszczą się mniej czy myOrdinarySpringBeanImportedFromOsgi jest importowany z usługi OSGi lub zdefiniowany jako zwykły zwykły Spring bean w tym samym kontekście aplikacji.

Te konfiguracje można łatwo przenieść na OSGI-INF/blueprint/, jeśli chcę oddzielić się od realizacji Gemini Blueprint, ale na razie wolę trzymać dwie połówki w tym samym miejscu, aby uniknąć bałaganu w strukturze katalogów .