Куди помістити файл конфігурації Spring?

Я хочу інтегрувати Spring Framework в свій проект, особливо на стороні сервера.

Отже, я не хочу розміщувати його в папці WEB-INF файлу війни.

Чи слід поміщати applicationContext.xml у кожен рівень (означає кожен проект, оскільки він розділений на окремі проекти? (Служби, Домен та DAO)

Яка хороша практика?

У цьому може допомогти структура файлів Maven

По суті , файли конфігурація Spring (які можуть мати будь-яке ім'я, до речі, не тільки родової applicationContext.xml) розглядаються як ресурси і шляхи до класам рубрик src/main/resources. Під час процесу збирання вони копіюються в WEB-INF/classesкаталог, який є нормальним місцем для цих файлів.

Варіації включають додатковий springкаталог (наприклад src/main/resources/spring) для відділення весняних контекстів від інших ресурсів, присвячених рамкам програми. Ви можете розділити контексти програми на виділені шари, такі як:

example-servlet.xml
example-data.xml
example-security.xml

і так далі.

Що щодо різних середовищ, таких як розробник / тест / виробництво?

Як правило, ваша конфігурація Spring повинна підбирати конфігурацію середовища з її, ах, середовища. Зазвичай це означає використання JNDI, JDBC, змінних середовища або файлів зовнішніх властивостей для забезпечення необхідної конфігурації. Я перелічую їх у порядку переваги, оскільки JNDI, як правило, легше адмініструвати, ніж файли зовнішніх властивостей у керованому виробничому кластері.

У разі тестування інтеграції вам може знадобитися використовувати "тестовий" весняний файл конфігурації. Це буде містити спеціальні контексти, які використовують тестові боби або конфігурацію. Вони можуть бути присутніми в src / test / ресурси і можуть мати test-префікс, щоб переконатися, що розробники знають про їх призначення. Типовим використанням буде надання джерела даних без JNDI, можливо, орієнтованого на базу даних HSQLDB під час автоматизованих тестів побудови, на яке посилається в тестовому випадку.

Однак, як правило, більшість файлів контексту Spring не повинні потребувати спеціалізованих модифікацій під час переміщення між рівнями. Має бути так, що той самий артефакт збірки (наприклад, файл WAR) використовується у розробці / тесті / виробництві лише з різними обліковими даними.

Ваш проект розділений на модулі Maven? Якщо так, ви можете додати додатковий модуль лише для конфігураційних файлів. Дозвольте викликати його конфігураційний модуль

config-module
      |
      |--> src\main\resources\config\spring\applicationContex.xml
      |--> src\main\resources\config\properties\application.properties
      |--> pom.xml

Така конфігурація є пропозицією. Налаштуйте свій власний набір файлів Упакуйте його як JAR та додайте цей модуль як залежність від будь-якого іншого модуля (веб, вушна кришка, інша банка).

У вас буде доступ до ресурсів конфігураційного модуля (xml, властивості тощо), оскільки вони перебувають у класі.

пам’ятка веб-модуля

<dependency>
    <groupId>com.myproject.group</groupId>
    <artifactId>config-module</artifactId>
</dependency>

Потім використовуйте заяви про імпорт із зовнішніх файлів контексту Spring. Наприклад

<import resource="classpath*:com/package/subpackage/**/config/applicationContext.xml" />