Подтвердить что ты не робот

Как создать мультимодульную конфигурацию spring?

У меня есть многомодульная (maven) spring сборка. Все модули публикуют некоторые beans, и большинство также потребляют beans, определяемые далее по графику зависимости. Хотя большинство из них объявлено аннотацией beans, почти каждый модуль также имеет один или два объявленных xml beans.

Хотя у нас есть полупристойное решение, но мне действительно интересно, какой правильный/оптимальный способ организовать xml файлы в этом сценарии? Используете ли вы импорт между модулями или какой-то другой способ? Вы помещаете все xml файлы в одно место или распространяете их в соответствии с графиком зависимости? Как ваше решение обрабатывает частичные spring контексты (типичные интеграционные тесты)?

Я бы также хотел, чтобы это было организовано таким образом, чтобы я мог оптимально использовать поддержку IDE spring (IDEA и несколько пользователей eclipse).

4b9b3361

ОТВЕТЫ

Ответ 1

Мы используем подстановочный импорт в модулях, чтобы другие модули вносили вклад beans в модуль, объявляющий импорт:

<import resource="classpath*:com/acme/**/*-core-support.xml" />

Модульность

Модули, которые хотят внести вклад в "хост", просто должны помещать правильно названные файлы в src/main/resources/com/acme, чтобы в этом случае автоматически подбираться. Если вы используете сканирование классов (через <context:component-scan />, это станет еще проще).

Еще одна вещь, которая помогает в этом отношении, - это небольшое расширение Spring, которое поднимает beans данного типа и снова публикует их в ApplicationContext. Делая что-то вроде этого:

<plugin:list id="beanList" class="com.acme.MyCoolPluginInterface" />

<bean class="com.acme.MyPluginHost">
   <property name="plugins" ref="beanList" />
</bean>

В сочетании с подстановочным импортом это будет:

  • Соберите все beans, найденные в ApplicationContext, которые реализуют MyCoolPluginInterface и завершают их в список, зарегистрированный как beanList в ApplicationContext.
  • Разрешить MyPluginHost ссылаться на этот список.

Фактически, теперь вы можете просто расширить свое приложение, добавив модули плагина в путь к классам (так называемая зависимость в Maven).

Это маленькое расширение Spring называется плагином Spring и опубликовано под лицензией Apache 2. Подробнее см. http://github.com/SpringSource/spring-plugin. В Github также есть более продвинутый образец проекта, который показывает, как это работает и улучшает модульность в GitHub. Приложение - пример кода для моего "Упс! Где моя архитектура ушла?" которую вы видите здесь или смотрите запись здесь.

Различные среды

Обычно мы настраиваем наши приложения для работы в целевой среде (используя JNDI-запросы и прочее). Конечно, вы хотели бы использовать стандартные механизмы PropertyPlaceholderConfigurer для экстернализации конфигурации, которые должны быть затронуты администраторами или будут меняться через различные среды.

Для тестов интеграции мы обычно имеем дополнительные файлы конфигурации в src/main/test, которые дополнительно загружаются в обычные файлы конфигурации, переопределяя критический beans, которые привязывают конфигурацию к среде. Например. если у вас есть источник данных в вашем обычном файле конфигурации

 <jee:jndi-lookup id="dataSource" jndi-name="jdbc/MyDataSource" />

вы бы переопределили это в своем test-context.xml, используя

 <bean id="dataSource" class="...DataSource" />
    <!-- config -->
 </bean>

и импортируя это после оригинала в тестовом классе

 @ConfigurationContext(locations = {"app-context.xml", "test-context.xml"})
 public FooBarIntegrationtest {
   // ...
 }

Ответ 2

Мы просто создаем контекст приложения из нескольких файлов конфигурации XML на основе использования.

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

При развертывании мы обращаемся к услугам через Spring Remoting, и, таким образом, клиент использует контекст приложения, который инициализируется через конфигурацию XML, которая определяет прокси-сервер beans, который позволяет удалять. Между тем службы объединены теми же XML файлами, которые используются в тестовых примерах, но контекст приложения теперь загружается либо DispatcherServlet, либо EJB или MDB.

Эта настройка позволяет нам адаптировать контекст приложения для каждого сценария без необходимости дублировать любую информацию в файлах конфигурации, что упрощает обслуживание. Кроме того, нет жесткой зависимости между конфигурационными файлами через импорт, поскольку это обрабатывается на уровне выше, который фактически создает ApplicationContext.

Не могу комментировать поддержку IDE, так как мы еще не используем ее.