Как получить данные из файла property spring

Обновлено: 04.07.2024

однако я работаю над обычным Java-проектом с Spring (без веб-приложения и тому подобного). Но я хотел бы получить некоторые общие свойства из файла свойств, и это необходимо использовать в файле JAVA. Как достичь этого с помощью Spring / Spring Аннотации?

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

мое понимание-это контекст приложения.xml используется только для веб-проектов. Если нет, как я должен настроить это приложение-контекст.xml, поскольку у меня нет интернета.xml для определения контекста приложения.в XML

вы можете создать контекст приложения на основе XML, например:

если xml-файл находится на пути к вашему классу. Кроме того, вы можете использовать файл в файловой системе:

дополнительная информация доступна в Spring reference docs. Вы также должны зарегистрировать завершение работы крючком для обеспечения изящного выключения:

Далее, вы можете использовать PropertyPlaceHolderConfigurer для извлечения свойства '.файл свойств и ввести их в ваши бобы:

наконец, если вы предпочитаете конфигурацию на основе аннотаций, вы можете использовать @Value аннотация для ввода свойств в вас бобы:

вам не нужно использовать Spring. Вы можете читать с простой java, как это:

С весны 4, Вы можете использовать @PropertySource аннотация весной @Configuration класс:

если вы хотите иметь свою конфигурацию вне своего пути к классам, вы можете использовать file: префикс:

кроме того, вы можете использовать переменную среды, чтобы определить файл

здесь APP_PROPERTIES - это переменная среды, которая имеет значение местоположения файла свойств, например /path/to/application.properties .

пожалуйста, прочитайте мой пост в блоге Весна @PropertySource подробнее о @PropertySource , его использование, как можно переопределить значения свойств и как можно указать дополнительные источники свойств.

вы можете выяснить, как ваш проект будет использоваться во всем приложении? Если ваш проект используется в качестве пути сборки для веб-приложения, а конфигурация в вашем проекте достигается с помощью аннотаций spring, поэтому вы, несомненно, озадачены тем, как добавить . Я предлагаю вам объявить парней, которые будут использовать ваш проект, сказать им, что вам нужно, и вам просто нужно добавить @Value("$") в коде.

Я хочу получить доступ к значениям, указанным в application.properties , например:

Я хочу получить доступ к userBucket.path в моей основной программе в приложении Spring Boot.

21 ответ

Вы можете использовать аннотацию @Value и получить доступ к свойству в любом используемом вами компоненте Spring.

Раздел Внешняя конфигурация загрузки Spring docs, объясняет все детали, которые могут вам понадобиться.

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

Ниже приведен соответствующий класс читателя.

Теперь мы можем автоматически подключать класс считывателя везде, где мы хотим получить доступ к значениям свойств. например

Вы можете использовать @ConfigurationProperties, это просто и легко получить доступ к значению, определенному в application.properties

У меня тоже была эта пробема. Но есть очень простое решение. Просто объявите свою переменную в конструкторе.

application.properties:

Класс Session ServiceImpl:

Этот подход не использует аннотацию загрузки Spring. Традиционный способ обучения.

Используйте метод getProperty () для передачи ключа и доступа к значению в файле свойств.

Есть 2 способа получить доступ к значению из файла application.properties

  1. Использование аннотации @Value
  1. Использование экземпляра класса среды

Вы также можете ввести экземпляр среды с помощью инъекции конструктора или самостоятельно создать bean-компонент

  1. вы можете напрямую использовать @Value в своем классе
  1. Чтобы сделать его чистым, вы можете очистить класс @Configuration , куда вы можете добавить все свои @value

Лучше всего использовать аннотацию @Value , она автоматически присвоит значение вашему объекту private Environment en . Это уменьшит размер кода и упростит фильтрацию файлов.

Наилучшие способы получения значений свойств используются.

1. Использование аннотации значений

2. Использование компонента Environment

Для меня ничего из вышеперечисленного не помогло мне напрямую. Я сделал следующее:

В дополнение к ответу @Rodrigo Villalba Zayas я добавил
implements InitializingBean в класс
и реализовал метод

Так это будет выглядеть

Вы можете использовать аннотацию @Value для чтения значений из файла application.properties/yml.

Вы можете использовать @Value("$") из application.properties, если ваш класс аннотирован @Configuration или @Component .

Есть еще один способ, который я опробовал, - это создать класс Utility для чтения свойств следующим образом:

Вы можете использовать статический метод, чтобы получить значение ключа, переданного в качестве параметра.

Spring-boot позволяет нам несколькими способами предоставлять внешние конфигурации, вы можете попробовать использовать файлы application.yml или yaml вместо файла свойств и предоставить различные настройки файлов свойств в соответствии с различными средами.

Мы можем разделить свойства для каждой среды в отдельные файлы yml в отдельных профилях Spring. Затем во время развертывания вы можете использовать:

Чтобы указать, какой профиль пружины использовать. Обратите внимание, что имена файлов yml должны быть такими, как

Для их автоматического захвата пружинным ботинком.

Чтобы прочитать из application.yml или файла свойств:

Самый простой способ прочитать значение из файла свойств или yml - использовать аннотацию spring @value. Spring автоматически загружает все значения из yml в среду Spring, поэтому мы можем напрямую использовать эти значения из окружающая среда как:

Или другой метод, который Spring предоставляет для чтения строго типизированных bean-компонентов, выглядит следующим образом:

Соответствующий POJO для чтения yml:

Вышеупомянутый метод хорошо работает с файлами yml.

Приложение может считывать 3 типа значений из файла application.properties.

Файл класса

Если у вас нет свойства в application.properties, вы можете использовать значение по умолчанию

Следуй этим шагам. 1: - создайте свой класс конфигурации, как показано ниже.

2: - когда у вас есть класс конфигурации, введите переменную из нужной конфигурации.

Вы можете использовать @Value для загрузки переменных из application.properties , если вы будете использовать это значение в одном месте, но если вам нужен более централизованный способ загрузки этих переменных, @ConfigurationProperties - лучший подход .

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

В настоящее время я знаю о следующих трех способах:

1. Аннотация @Value

  • По моему опыту, бывают ситуации, когда вы не может получить значение или установлено на null . Например, когда вы пытаетесь установить его в методе preConstruct() или init() . Это происходит потому, что внедрение значения происходит после того, как класс полностью построен. Поэтому лучше использовать третий вариант.

2. Аннотация @PropertySource

  • PropertySouce устанавливает значения из исходного файла свойств в переменной Environment (в вашем классе), когда класс загружается. Таким образом, вы можете легко получить послесловие.
    • Доступно через переменную системной среды.

    3. Аннотация @ConfigurationProperties .

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

    Он инициализирует сущность на основе данных о свойствах.

    • @ConfigurationProperties указывает файл свойств для загрузки.
    • @Configuration создает компонент на основе переменных файла конфигурации.

    Вы тоже можете это сделать .

    Затем, где бы вы ни хотели читать из application.properties, просто передайте ключ методу getConfigValue.

    @ConfigurationProperties может использоваться для отображения значений из .properties ( .yml также поддерживается) в POJO.

    Рассмотрим следующий пример файла.

    Теперь к значению свойств можно получить доступ путем автоматического подключения employeeProperties следующим образом.

    Springboot: понимание application.properties и application.yaml

    Springboot: понимание application.properties и application.yaml

    Предисловие: Изучив или используя фреймворк springboot, вы обнаружите, что есть два способа настроить файл в Springboot, а именно формат .properties и формат .yaml, оба из которых являются файлами конфигурации, но в чем разница между ними? ?

    application.properties

    1. Проблемы с местоположением

    При создании проекта Spring Boot по умолчанию в каталоге ресурсов находится файл application.properties. Вы можете настроить проект в файле application.properties, но этот файл не единственный файл конфигурации. В Spring Boot есть 4 места для хранения Файл конфигурации сокращается в соответствии со следующим приоритетом:

    1. Под config в корневом каталоге текущего проекта
    2. В корневом каталоге текущего проекта
    3. В каталоге config каталога ресурсов
    4. каталог ресурсов


    Когда проект springboot запускается, он по умолчанию найдет и загрузит свойства файла конфигурации в порядке из четырех указанных выше мест, но мы также можем настроить расположение файла конфигурации, например: создать тестовый каталог в каталоге ресурсов и создать конфигурацию application.properties в тестовом каталоге. File, но этот файл не будет автоматически загружен, что требует от нас указать расположение файла конфигурации через spring.config.location. В это время запустите проект. Проект будет запускаться с конфигурационным файлом classpath: /test/application.properties следующим образом:



    Запустите проект springboot и получите следующие результаты:

    2. Проблема с именем файла

    На этом этапе у некоторых людей могут возникнуть вопросы. Должен ли файл конфигурации быть application.properties? Мы знаем, что суффикс файла конфигурации - это свойства. Фактически, приложение можно изменить, но поскольку имя загрузки по умолчанию - application в проекте springboot, Итак, мы пишем приложение по умолчанию, так как же изменить название?

    Например, мы создаем файл с именем loadme.properties в каталоге ресурсов, а затем указываем его в конфигурации IEDA:


    После того, как обозначение завершено, система запускаемого проекта по-прежнему будет искать по очереди из четырех вышеуказанных мест, но поиск будет выполняться по имени loadme.properties, то есть файл конфигурации может быть настроен конфигурацией, только spring.config требуется для указания конфигурации

    3. Внедрение обычных атрибутов

    Springboot возник из spring, поэтому внедрение свойств все еще существует в проекте springboot. В проекте springboot файл application.properties автоматически загружается по умолчанию, поэтому простое внедрение свойств может быть записано непосредственно в этот файл конфигурации

    one. Определите студенческий класс:

    two. Определите свойства в файле application.properties

    three.Вставьте эти атрибуты непосредственно в объект Student через аннотацию @Value.

    fourСам объект .Student также должен быть передан в контейнер Spring для управления. Если Student не передан в контейнер Spring, свойства в Student не могут быть получены из контейнера Spring; после завершения настройки вы можете ввести объект Student в Контроллер и запустить Project, вы можете видеть, что в объект были добавлены свойства, например:


    etc: Вообще говоря, нам нужно создать новый файл конфигурации student.properties в каталоге ресурсов, чтобы не повлиять на системный файл конфигурации application.properties. Student.properties такой же, как указано выше:

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

    Если он находится в конфигурации Java, вы можете использовать @PropertySource, чтобы ввести конфигурацию:

    Конечно, это простое использование инъекции свойств в Spring и не имеет ничего общего с Spring Boot.

    4. Введите добавление атрибутов безопасности.

    Spring Boot вводит типобезопасное внедрение свойств. Если в Spring принят метод конфигурации, когда настроено много свойств, рабочая нагрузка будет тяжелой и подверженной ошибкам, поэтому мы используем типобезопасную инъекцию свойств для решения этой проблемы следующим образом:

    Введите аннотацию @ConfigurationProperties (prefix = «student»), настройте префикс свойства, в это время соответствующие данные в контейнере Spring будут автоматически вводиться в соответствующее свойство объекта, избегая последовательной инъекции через аннотацию @Value, уменьшая рабочую нагрузку и Избегайте ошибок

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

    Кодовый стиль

    Используйте примечание yml:

    • Разные «уровни» разделяются двоеточием.
    • Перед подуровнем есть пространство, и вы не можете использовать вкладку
    • Если после двоеточия стоит значение, между двоеточием и значением должен быть хотя бы один пробел, чтобы избежать тесного контакта.
    • Либо используйте application.properties, либо application.yml, не беспокойтесь

    Вообще говоря, yaml отличается от беспорядка файла свойств. Конфигурация yaml упорядочена. Это очень полезно в некоторых конфигурациях. Например, в конфигурации Spring Cloud Zuul, когда мы настраиваем правила прокси, порядок особенно важен ; Конечно, конфигурация yaml не является панацеей, например, конфигурация yaml в настоящее время не поддерживает аннотации @PropertySource и т. Д.

    Заключение: это конец введения в два файла конфигурации в проекте springboot. Некоторые друзья могут не понимать yml и yaml в приведенном выше обсуждении. На самом деле, это не оказывает большого влияния на использование. Если вы хотите узнать об этом большекликните сюда

    Интеллектуальная рекомендация


    Michael.W Поговорите о Hyperledger Fabric. Проблема 20 - Подробная индивидуальная сортировка узла с пятью порядками с исходным кодом для чтения.

    Michael.W Поговорите о Hyperledger Fabric. Проблема 20 - Подробная индивидуальная сортировка узла с пятью порядками с исходным кодом чтения Fabric Файл исходного кода одиночного режима находится в ord.


    Мяу Пасс Матрица SDUT

    Мяу Пасс Матрица SDUT Time Limit: 1000 ms Memory Limit: 65536 KiB Submit Statistic Problem Description Лянцзян получил матрицу, но эта матрица была особенно уродливой, и Лянцзян испытал отвращение. Чт.


    Гессенская легкая двоичная структура удаленного вызова

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


    TCP Pasket и распаковка и Нетти Solutions

    Основные введение TCP является ориентированным на соединение, обеспечивая высокую надежность услуг. На обоих концах (клиенты и терминалы сервера) должны иметь один или более гнезда, так что передающий.


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

    Проблема

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

    Решение

    Лучшее решение этой проблемы — вывод данных конфигурации приложения во внешний источник. Нам не нужно будет каждый раз заново компилировать код при переключении среды. Мы сможем переопределить значения параметров конфигурации, затратив меньше усилий. Наше приложение Spring сможет считывать значения коммерческого счета из внешних источников, например переменных среды, аргументов командной строки и файлов свойств.

    Вывод данных конфигурации во внешний источник

    Источники свойств

    Существуют различные способы вывода данных конфигурации приложения Spring во внешний источник. Для задания свойств приложения мы можем использовать переменные среды, файлы свойств (например, в формате YAML или с расширением *.properties) и аргументы командной строки. Мы также можем хранить файлы свойств в произвольных местах и сообщать приложению Spring, где их искать.

    Файлы свойств

    По умолчанию приложение Spring загружает свойства из файлов application.properties или application.yml из перечисленных ниже источников в порядке приоритета (то есть вышестоящий файл свойств переопределяет файлы из источников нижнего уровня) и добавляет их в среду:

    подкаталог конфигурации текущего каталога;

    пакет конфигураций в параметре classpath;

    корневой каталог classpath.

    По умолчанию имя файла конфигурации — application. При желании мы можем указать другое имя, используя ключ свойств среды spring.config.name . В примере ниже мы переопределили имя конфигурации Spring, заданное по умолчанию, на new_name .

    Пользовательское место хранения

    Мы можем задать внешний источник свойств приложения или файлов YAML с помощью свойства среды spring.config.location . Это свойство может указывать на любое пользовательское место хранения и таким образом переопределять местоположение по умолчанию. См. пример ниже:

    Примечание. При указании расположения каталога необходимо убедиться, что после значения spring.config.location стоит символ / (например, spring.config.location=classpath:/config/ ) и что задано имя файла конфигурации по умолчанию. Также с помощью ключа свойств spring.config.additional-location можно указать дополнительные каталоги, поиск в которых будет проводиться перед поиском в местоположениях по умолчанию.

    Spring Boot также поддерживает обобщенное указание местоположения с помощью подстановочных символов. Эта функция полезна в средах с несколькими источниками свойств конфигурации, таких как среды Kubernetes. Например, у вас есть конфигурации Redis и MySQL. Они могут храниться в разных местах, но при этом они обе должны быть указаны в файле application.properties , чтобы их видело приложение. Это может привести к тому, что два отдельных файла application.properties будут смонтированы в разных местах, например /config/redis/application.properties и /config/mysql/application.properties . В таком случае использование обобщенного указания каталога config/*/ позволит обрабатывать оба файла.

    Форматы файлов

    Файл свойств приложения может быть в формате YAML или иметь расширение .properties. Если эти два файла свойств будут храниться в одной и той же папке конфигурации, файл application.properties будет иметь приоритет над файлом application.yml . В следующем фрагменте кода показаны настройки коммерческого счета, определенные в файле свойств каждого типа.

    application.properties

    application.yml

    Файлы форматов YAML и .properties

    YAML — это легкочитаемый стандарт сериализации данных, часто применяемый в файлах конфигурации. Он является надмножеством формата JSON и очень удобен при составлении иерархической конфигурации. Файлы формата YAML предпочтительны, поскольку они более понятны и удобочитаемы, особенно по сравнению с файлами .properties. Помимо этого, у них есть другие очень полезные функции, например безопасность типов и т. д.

    Для загрузки файла YAML приложению Spring требуется библиотека SnakeYAML в параметре classpath . В приведенном примере кода использованы стартеры Spring Boot, поэтому необходимости включать данную библиотеку в параметр classpath нет.

    Множество профилей

    YAML позволяет указать несколько профилей в одном файле конфигурации, тогда как при использовании файла .property нам может потребоваться файл конфигурации для каждого профиля. Рассмотрим следующий пример.

    1. Файл YAML

    application.yml

    2. Файл .properties

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

    application-development.properties

    application-production.properties

    При наличии свойств, общих для профилей разработки и эксплуатации, нам может потребоваться файл application.properties, заданный по умолчанию.

    application.properties

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

    Вы можете узнать больше о профилях Spring в этой статье.

    Читаемость

    YAML поддерживает списки и карты в виде иерархических свойств, и по сравнению с файлом расширения .properties версия YAML более удобочитаемая. Допустим, мы хотим настроить параметры подключения для реальной и тестовой сред. Сначала зададим имена подключений в виде списка, а затем сопоставим их с соответствующими URL-адресами с помощью карты, как показано ниже. Рассмотрим, как реализация в YAML может упростить эту конфигурацию в сравнении с файлом .properties.

    application.yml

    application.properties

    Тестовые примеры для проверки сопоставлений можно найти в тестовых пакетах с примером кода из данной статьи.

    Аргументы командной строки

    Когда мы вводим аргумент командной строки, приложение Spring преобразует его в свойство и добавляет в Spring Environment. С помощью этих аргументов можно сконфигурировать параметры приложения. К примеру, следующие аргументы командной строки переопределят порт сервера приложения, заданный любым другим источником свойств. При запуске приложения командой Maven или Java мы все равно получим тот же результат.

    Команда Maven:

    Команда JVM:

    Также можно вводить несколько аргументов одновременно. Дополним приведенный выше пример еще одним свойством — портом сервера, как показано ниже.

    Команда Maven (через пробел):

    Команда JVM:

    Переменные среды

    Если у нас нет возможности изменять значения свойств через командную строку, на выручку приходят переменные среды. Приложение Spring может считывать свойства из них. При запуске оно ищет переменную среды под именем SPRING_APPLICATION_JSON , которая может содержать набор свойств JSON в одностроковом формате. Мы можем поэкспериментировать и переопределить адреса подключения, указанные в нашем файле свойств, как описано ниже.

    Откроем терминал и выполним следующую команду. Она устанавливает переменные среды приложения, переопределяя настройки подключения.

    После этого запустим наше приложение:

    Результат

    Проверив журнал, мы заметим, что адреса подключения в профиле разработки были переопределены, а значения в файле JSON, который мы передали через переменную среды, были в приоритете.

    Передача свойств

    Существуют различные способы передачи значений свойств в приложение из соответствующих источников. Мы можем использовать аннотацию @Value абстракции Spring Environment или привязать эти значения к структурированному объекту с аннотацией @ConfigurationProperties .

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

    Важно убедиться, что имя свойства @Value совпадает с именем, указанным в источниках свойств.

    При наличии нескольких свойств мы можем сгруппировать их и сопоставить с классом POJO. Таким образом, мы получим структурированный и типобезопасный объект, который сможем внедрить в любое место в нашем приложении. Поэтому вместо использования аннотации @Value значения свойств можно получить с помощью метода чтения значения класса POJO.

    Класс POJO должен иметь аннотации @ConfigurationProperties и @Component , как описано выше. Значение префикса, указанное в аннотации, должно совпадать с префиксом свойства, определенного в файле application.yml .

    application.yml

    Важно отметить, что аннотация @ConfigurationProperties также позволяет нам сопоставлять списки и карты, как показано ниже:

    Порядок приоритета данных конфигурации

    В приложении Spring Boot может быть несколько источников свойств. Поэтому важно знать, какой источник свойства имеет наивысший приоритет. Например, если конфигурация нашего приложения находится в файле application.yml и во время выполнения приложения мы решаем передать аргументы командной строки, тогда значения свойств в файле application.yml будут переопределены значениями аргументов командной строки.

    В Spring Boot 2.2.x используется приведенный ниже порядок источников свойств. Источник свойств, расположенный выше в списке, имеет приоритет над источниками под ним.

    Свойства глобальных настроек в папке $HOME/.config/spring-boot , когда средства разработки активны.

    Аннотации @TestPropertySource в ваших тестах.

    Атрибут свойств в ваших тестах. Он доступен в @SpringBootTest и тестовых аннотациях для проверки работы определенного фрагмента вашего приложения.

    Аргументы командной строки.

    Свойства из SPRING_APPLICATION_JSON (строковый JSON в переменной среды или системном свойстве).

    Начальные параметры ServletConfig .

    Начальные параметры ServletContext .

    Атрибуты JNDI из java:comp/env .

    Свойства Java System, то есть System.getProperties() .

    Переменные среды ОС.

    RandomValuePropertySource , свойства которого хранятся только в random.* .

    Свойства приложения для конкретного профиля, за пределами упакованного файла .jar (application- .properties и варианты YAML).

    Свойства приложения для конкретного профиля внутри файла .jar ( application- .properties и варианты YAML).

    Свойства приложения за пределами упакованного файла .jar ( application.properties и варианты YAML).

    Свойства приложения в файле .jar ( application.properties и варианты YAML).

    Аннотации @PropertySource в классах @Configuration . Необходимо учесть, что такие источники свойств не добавляются в Environment, пока контекст приложения не будет обновлен. В этот момент уже поздно настраивать некоторые свойства, например logging.* и spring.main.*, которые считываются перед началом обновления.

    Свойства по умолчанию (заданные настройкой SpringApplication.setDefaultProperties ).

    Заключение

    Рекомендуется выносить данные конфигурации во внешний источник. Если свойств много, мы можем сгруппировать их в простой класс Java и использовать аннотацию @ConfigurationProperties , чтобы структурировать конфигурацию и сделать ее типобезопасной. Однако самая большая проблема при использовании внешних источников свойств заключается в правильном выборе конфигурации для разворачиваемого приложения. Поэтому важно соблюдать осторожность при настройке приложения, в котором для разных сред используются разные источники свойств. Пример кода для этой статьи доступен на GitHub.

    Читайте также: