Структура файла Maven может помочь с этим
По сути, файлы конфигурации Spring (которые, кстати, могут иметь любое имя, а не только общее имя applicationContext.xml
) обрабатываются как ресурсы classpath и хранятся в src/main/resources
. В процессе сборки они затем копируются в WEB-INF/classes
каталог, который является нормальным местом для этих файлов.
Варианты включают в себя дополнительный spring
каталог (например src/main/resources/spring
), чтобы отделить контексты Spring от других ресурсов, предназначенных для каркасов приложений. Вы можете разделить контексты приложения на выделенные слои, такие как:
example-servlet.xml
example-data.xml
example-security.xml
и так далее.
А как насчет различных сред, таких как dev / test / production?
Как правило, ваша конфигурация Spring должна подобрать конфигурацию среды из ее среды. Обычно это означает использование JNDI, JDBC, переменных среды или внешних файлов свойств для обеспечения необходимой конфигурации. Я перечисляю их в порядке предпочтения, поскольку JNDI, как правило, легче администрировать, чем внешние файлы свойств в управляемом производственном кластере.
В случае интеграционного тестирования вам может понадобиться использовать конфигурационный файл Spring «только для тестирования». Это будет содержать специальные контексты, которые используют тестовые компоненты или конфигурацию. Они будут присутствовать в каталоге src / test / resources и могут иметь test-
префикс, чтобы убедиться, что разработчики знают о своей цели. Типичное использование - предоставление источника данных не-JNDI, возможно, предназначенного для базы данных HSQLDB во время автоматических тестов сборки, на который будут ссылаться в тестовом примере.
Однако, как правило, большинство ваших контекстных файлов Spring не должны нуждаться в специальной модификации, поскольку они перемещаются между уровнями. Должно быть так, что один и тот же артефакт сборки (например, файл WAR) используется в dev / test / production только с разными учетными данными.