Конфигурация проекта с помощью Spring

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

For a Spring application there are several solutions you can use - от простых решений до сверхгибких и очень сложных альтернатив.

Одним из наиболее распространенных и простых решений является гибкое использованиеproperties files иfirst class property support provided by Spring.

В качестве доказательства концепции для целей этой статьи мы рассмотрим один конкретный тип свойства - конфигурацию базы данных. Имеет смысл использовать один тип конфигурации базы данных для производства, другой для тестирования и еще один для среды разработки.

Давайте начнем доказательство концепции - с определения среды, на которую мы хотим ориентироваться:

Далее - давайте создадим 3 файла свойств - по одному для каждой из этих сред:

В типичном приложении Maven они могут находиться вsrc/main/resources, но где бы они ни находились, при развертывании приложения они должны бытьavailable on the classpath.

Важное примечание -having all properties files under version control makes configuration much more transparent и воспроизводимо. Это противоречит тому, что где-то есть конфиги на диске и просто указывает на них Spring.

Весной мы добавим правильный файл в зависимости от среды:

То же самое можно, конечно, сделать и с настройкой Java:

Такой подход позволяет гибко использовать несколько файлов*.properties дляspecific, focused purposes. Например - в нашем случае конфиг постоянства Spring импортирует свойства персистентности - что имеет смысл. Конфигурация безопасности будет импортировать связанные с безопасностью свойства и так далее.

Последняя, ​​развертываемая войнаwill contain all properties files - для настойчивости три вариантаpersistence-.properties. Поскольку файлы на самом деле называются по-разному, нет никакого страха случайно включить неправильный. Мы установим * переменнуюenvTarget и, таким образом, выберем нужный экземпляр из множества существующих вариантов.

ПеременнаяenvTarget может быть установлена ​​в ОС / среде или в качестве параметра командной строки JVM:

Для интеграционных тестов, для которых требуется постоянство, мы просто установим свойствоenvTarget в pom.xml:

Соответствующий файлpersistence-h2_test.properties может быть помещен вsrc/test/resources, так что он будетonly be used for testing и не будет без необходимости включаться и развертываться с войной во время выполнения.

Есть несколько способов обеспечить дополнительную гибкость в этом решении, если это необходимо.

Один из таких способов - использоватьmore complex encoding for the names файлов свойств, указав не только среду, в которой они будут использоваться, но и дополнительную информацию (например, поставщик сохраняемости). Например, мы могли бы использовать следующие типы свойств:persistence-h2.properties,persistence-mysql.properties или, что более конкретно:persistence-dev_h2.properties,persistence-staging_mysql.properties,persistence-production_amazonRDS.properties.

Преимущество такого соглашения об именах - а этоjust a convention, поскольку в общем подходе ничего не меняется - просто прозрачность. Теперь стало намного понятнее, что делает конфигурация, только взглянув на имена:

В этой статье обсуждается гибкое решение для настройки среды в Spring. Альтернативное решение с использованием профилейcan be found here.

Реализацию решения можно найти вthe GitHub project - это проект на основе Maven, поэтому его будет легко импортировать и запускать как есть.