Объедините план OSGi и конфигурацию пружины

Question

Есть ли хорошие / лучшие практики в отношении сочетания конфигурации Spring и OSGi Blueprint (например, Gemini Blueprint)? Какие файлы XML вы используете? Где вы положили их в свои OSGi комплекты (META-INF/spring, OSGi-INF)? Какие из этих методов позволят вам повторно использовать ваши пакеты в сочетании с реализацией Blueprint, не относящейся к Gemini?

Справочная информация: мы находимся в процессе перехода от Spring/Spring DM на Spring/Blueprint. Я знаю, что Blueprint определяет <bean> элемент. Однако мы иногда сталкиваемся с ситуацией, когда ограниченные возможности определения компонентов спецификации Blueprint не отвечают всем нашим потребностям. Таким образом, представляется хорошим выбором использовать конфигурацию Spring в наших пакетах и ​​Blueprint для проводки пакетов через сервисы OSGi.

Answer 1

Какие файлы XML вы используете? Где вы кладете их в свои OSGi-комплекты (META-INF/spring, OSGi-INF)? Какие из этих методов позволят вам повторно использовать ваши пакеты в сочетании с реализацией Blueprint, не относящейся к Gemini?

Gemini Blueprint одинаково относится к обоим этим каталогам, но OSGI-INF/blueprint/*.xmlявляется единственным, указанным в общей спецификации OSGi Blueprint.

Предлагаемая практика из документации Gemini Blueprint:

[...] Рекомендуется разделять конфигурацию контекста приложения по крайней мере на два файла, названных по соглашению modulename-context.xml и modulename-osgi-context.xml. Файл modulename-context.xml содержит стандартные определения bean-компонентов, не зависящие от знаний OSGi. Файл modulename-osgi-context.xml содержит определения компонентов для импорта и экспорта служб OSGi. Он может (но не обязан) использовать схему OSGi Gemini Blueprint в качестве пространства имен верхнего уровня вместо пространства имен Spring 'beans'.

Я попробовал это, и это прекрасно работает. Я использую Gemini Blueprint для одного из моих проектов, в котором есть файлы META-INF/spring/context.xml, который определяет мои бобы и их отношения, и META-INF/spring/osgi-context.xml, который определяет, какие компоненты должны быть представлены как /import из служб OSGi и как. context.xml похоже

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

и является обычным обычным контекстом приложения Spring без конфигурации Blueprint/OSGi. osgi-context.xml похоже

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

Вы могли бы, конечно, использовать <beans> здесь также есть пространство имен и корневой элемент, но вам нужно определить xmlns:osgi и префикс службы так: <osgi:service .../> чтобы это работало. В моем случае мне не нужны специфичные для Gemini Blueprint, поэтому я доволен этой общей конфигурацией Blueprint. Точно так же я мог бы использовать <blueprint> пространство имен в context.xml также, но это конкретное приложение является старым, портированным на OSGi, поэтому я предпочитаю пока сохранять эту конфигурацию Spring специфичной.

Другое приложение в свою очередь имеет свои osgi-context.xml лайк

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

и в настоящее время не имеет, но может иметь context.xml лайк

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

и на самом деле не все равно, myOrdinarySpringBeanImportedFromOsgi импортируется из службы OSGi или определяется как обычный обычный бин Spring в том же контексте приложения.

Эти META-INF/osgi-context.xml конфигурации могут быть тривиально перенесены в OSGI-INF/blueprint/ если я хочу отделить себя от реализации Gemini Blueprint, но на данный момент я предпочитаю хранить две половины в одном месте, чтобы не испортить структуру каталогов.

Answer 2

Файлы с чертежами должны находиться в OSGI-INF/blueprint/ и называться *.xml (обычно blueprint.xml). Это расположение соответствует спецификации OSGi 4.2 Blueprint и будет работать с Aries или Gemini.

Файлы Spring-DM (как вы, вероятно, знаете) находятся в каталоге META-INF/spring/ и также называются *.xml (обычно beans.xml).

Оба файла должны быть в состоянии мирно сосуществовать. Они будут работать, только если у вас есть поддержка для каждого установленного контейнера.

Подключение должно быть выполнено через реестр услуг OSGi.

Что касается миграции, мы остановились на Spring-DM для возможностей, которые мы не могли сделать в Blueprint. Все остальное было перенесено в Blueprint.