Ответ 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 {
// ...
}