Spring компонент-сканирование в OSGi ничего не находит - PullRequest
5 голосов
/ 30 ноября 2011

Используя определения Spring-Context MANIFEST , я пытаюсь выполнить component-scan для поиска пакетов для аннотированных bean-компонентов Spring. Моя конфигурация Spring XML выглядит примерно так:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:context="http://www.springframework.org/schema/context"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
        http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd
        http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd">

    <!-- Scans the classpath of this application for @Components to deploy as 
        beans -->
    <context:component-scan
        base-package="com.some.other.module.one,com.another.module.two" />

    <context:annotation-config />
....

</beans>

В MANIFEST я импортирую пакеты, содержащие классы с аннотациями Spring. Однако, когда я проверяю ApplicationContext, в нем нет аннотированных bean-компонентов.

Я полагаю, что это происходит, потому что сканируемые пути к классам находятся в разных пакетах. Эти пакеты напрямую не импортируют пакеты с классами, в которых есть аннотации Spring. Что сбивает с толку, так это то, что Spring не выбирает путь к классу основного пакета, из которого запускается компонентное сканирование? Кажется, что он использует classpath каждого пакета, когда выполняет сканирование classpath. Есть ли способ заставить сканирование пути к классам использовать путь к классу пакета, в котором начинается сканирование?

Редактировать

Как сказал Данаил Начев ниже, когда Spring выполняет сканирование пути к классам, это происходит только внутри модуля, в котором происходит путь к классам. Обходной путь должен использовать:

  1. Поместите свои конфигурации для модуля в bean-компонент Spring 3 @Configuration.
  2. Используйте файл XML в вашем пакете верхнего уровня, который инициализирует компонент @Configuration.
  3. В компоненте верхнего уровня @Configuration используйте @Import для импорта других файлов конфигурации.
  4. Убедитесь, что в манифесте указано Require-Bundle, чтобы обеспечить доступность импортируемой конфигурации.

1 Ответ

7 голосов
/ 01 декабря 2011

OSGi - это модульная система, поэтому очень важно иметь четкое разделение между пакетами. Если Spring может пойти и объединить их под одним ApplicationContext, он не будет отличаться от обычного приложения Spring, где все доступно в одном пути к классам. Как то так.

Что происходит, так это то, что каждый пакет получает свой собственный ApplicationContext. Эти ApplicationContexts могут обмениваться bean-компонентами с помощью OSGi Service Registry. Вам нужно пометить компоненты как экспортированные и импортировать их в другие ApplicationContexts, иначе они не будут видны друг другу.

Это должно объяснить, почему вы не можете настроить все с одним контекстом Spring и ожидать, что, начиная с одного пакета, он пойдет и найдет все компоненты. Контекст Spring сканирует только один пакет и, при желании, может импортировать / экспортировать bean-компоненты как сервисы OSGi.

Отсюда: Глава 8. Упаковка и развертывание приложений OSGi на основе Spring

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...