Как загрузить файл properties java spring classpathresource

Обновлено: 03.07.2024

Я хочу получить доступ к значениям, указанным в 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 следующим образом.


    Большинство наших приложений зависят от внешних сервисов, например серверов баз данных, 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.

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

    Дальнейшее чтение:

    Руководство по связке ресурсов

    Загрузите ресурс в виде строки весной

    2. Использование ресурса

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

    Давайте начнем с рассмотрения различных методов получения экземпляра Resource .

    2.1. Вручную

    Для доступа к ресурсу из пути к классам мы можем просто использовать ClassPathResource :

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

    Однако мы также можем указать загрузчик классов для использования либо напрямую:

    Или косвенно через указанный класс:

    Обратите внимание , что из Resource мы можем легко перейти к стандартным представлениям Java, таким как InputStream или Файл .

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

    Приведенный выше путь к файлу относится к классу Example //.

    2.2. Использование @Value

    Мы также можем ввести Ресурс с @Value :

    @Value поддерживает и другие префиксы, такие как file: и url: .

    2.3. Использование ResourceLoader

    Если мы хотим лениво загружать наш ресурс, мы можем использовать ResourceLoader :

    Затем мы извлекаем наш ресурс с помощью getResource :

    Обратите также внимание, что ResourceLoader реализован всеми конкретными ApplicationContext s, что означает, что мы также можем просто зависеть от ApplicationContext , если это лучше соответствует нашей ситуации:

    3. Использование ресурсов

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

    Если мы видим использование ResourceUtils в нашем коде:

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

    4. Чтение Данных Ресурсов

    Давайте представим, что у нас есть следующий файл data/employees.данные , по пути к классу :

    4.1. Чтение в виде файла

    Теперь мы можем прочитать его содержимое, вызвав GetFile:

    Хотя следует отметить, что при таком подходе ожидается, что ресурс будет присутствовать в файловой системе, а не в файле jar.

    4.2. Чтение в качестве входного потока

    Допустим, однако, что наш ресурс находится внутри банки.

    Тогда мы можем вместо этого прочитать Resource как InputStream :

    5. Заключение

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

    У меня есть несколько файлов свойств, которые я хочу загрузить из пути к классам. Есть один набор по умолчанию, /src/main/resources который является частью myapp.jar . Я springcontext ожидаю, что файлы будут в пути к классам. т.е.

    Мне также нужна возможность переопределить эти свойства с помощью внешнего набора. У меня есть внешняя папка конфигурации cwd . Согласно весенней папке конфигурации загрузочного документа должна быть в пути к классам. Но из документа не ясно, будет ли он отменять только applicaiton.properties оттуда или все свойства в config.

    Когда я его тестировал, он только application.properties подбирается, а остальные свойства все еще подбираются /src/main/resources . Я пытался предоставить их в виде списка, разделенного запятыми, spring.config.location но набор по умолчанию все еще не отменяется.

    Как сделать так, чтобы несколько внешних файлов конфигурации переопределяли файлы по умолчанию?

    В качестве обходного пути я сейчас использовал app.config.location (свойство приложения), которое я предоставляю через командную строку. т.е.

    и я изменил свой applicationcontext на

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

    Я действительно хотел бы не использовать вышеуказанный обходной путь и иметь Spring переопределить все внешние файлы конфигурации в пути к классам, как это делается для application.properties файла.

    Они application.properties всегда будут загружаться, и spring.config.location вы можете добавить дополнительные местоположения конфигурации, которые проверяются на наличие файлов (то есть, когда он заканчивается на a / ), однако, если вы поместите туда список, разделенный запятыми, который указывает на файлы, которые будут загружены. Это также объясняется в Справочном руководстве по Spring Boot здесь

    При использовании Spring Boot свойства загружаются в следующем порядке (см. Внешняя конфигурация в справочном руководстве Spring Boot).

    1. Аргументы командной строки.
    2. Свойства системы Java (System.getProperties ()).
    3. Переменные среды ОС.
    4. Атрибуты JNDI из java: comp / env
    5. RandomValuePropertySource, который имеет только случайные свойства. *.
    6. Свойства приложения за пределами вашего упакованного jar-файла (application.properties, включая YAML и варианты профиля).
    7. Свойства приложения, упакованные внутри вашего jar-файла (application.properties, включая YAML и варианты профиля).
    8. Аннотации @PropertySource в ваших классах @Configuration.
    9. Свойства по умолчанию (указываются с помощью SpringApplication.setDefaultProperties).

    При разрешении свойств (т.е. @Value("$") разрешение выполняется в обратном порядке (т.е. начиная с 9).

    Чтобы добавить разные файлы, вы можете использовать spring.config.location свойства, которые принимают список файлов свойств, разделенных запятыми, или расположение файла (каталоги).

    Вышеупомянутый добавит каталог, в котором будут запрашиваться application.properties файлы.

    Это добавит 2 файла свойств к загружаемым файлам.

    Файлы конфигурации и местоположения по умолчанию загружаются перед дополнительными указанными spring.config.location , что означает, что последние всегда переопределяют свойства, установленные в более ранних. (См. Также этот раздел Справочного руководства по Spring Boot).

    Если он spring.config.location содержит каталоги (в отличие от файлов), они должны заканчиваться на / (и к ним будут добавлены имена, сгенерированные spring.config.name до загрузки). classpath:,classpath:/config,file:,file:config/ Всегда используется путь поиска по умолчанию , независимо от значения spring.config.location . Таким образом, вы можете установить значения по умолчанию для своего приложения в application.properties (или любом другом базовом имени, которое вы выберете spring.config.name ) и переопределить его во время выполнения другим файлом, сохранив значения по умолчанию.

    ОБНОВЛЕНИЕ: поскольку поведение spring.config.location теперь переопределяет значение по умолчанию, а не добавляет к нему. Вам нужно использовать spring.config.additional-location, чтобы сохранить значения по умолчанию. Это изменение поведения с 1.x на 2.x

    Как указано в документе, он будет выбран, как и другие местоположения по умолчанию для application.properties и application-[env].properties . Не учитываются другие файлы свойств. Об этом также говорится в справочнике (в разделе, на который ведет ссылка, и цитате из справочника). Да, но это то, что для меня не имеет смысла . зачем рассматривать только один вид файла из каталога в пути к классам, а не весь каталог. Это заставляет вас использовать только один файл свойств, что не очень хорошо. Как и в tomcat, я могу настроить common.loader, чтобы поместить конкретный каталог (и все, что в нем) в путь к классам, почему загрузчик классов не может его поддерживать. Цитирование документации бесполезно. Если бы документация была ясной (достаточной? Особенно нужным образом?), Тогда вопрос не возникал бы. Например, в этом случае действительно непонятно, как config.location и как config.names взаимодействовать, хотя, вероятно, кажется понятным людям, которые уже знают, как они взаимодействуют. Можете ли вы обновить свой ответ, чтобы добавить что-нибудь в документацию? Это должно быть обновлено, так как поведение spring.config.location now переопределяет значение по умолчанию, а не добавляется к нему. Вам нужно использовать, spring.config.additional-location чтобы сохранить значения по умолчанию. Это изменение поведения с 1.x на 2.x.

    При загрузке Spring Spring.config.location действительно работает, просто предоставьте файлы свойств, разделенные запятыми.

    можно поместить в приложение версию jdbc.properties по умолчанию. На этом можно установить внешние версии.

    На основе значения профиля, установленного с помощью свойства spring.profiles.active, будет выбрано значение jdbc.host. Итак, когда (в окнах)

    jdbc.host будет принимать значение из jdbc-dev.properties.

    jdbc.host будет принимать значение из jdbc.properties.

    Spring boot 1.X и Spring Boot 2.X не предоставляют те же параметры и поведение, что и Externalized Configuration .

    Очень хороший ответ М. Дейнума относится к особенностям Spring Boot 1.
    Я обновлюсь до Spring Boot 2 здесь.

    Источники и порядок свойств среды

    Spring Boot 2 использует очень особый PropertySource порядок, который предназначен для разумного переопределения значений. Свойства рассматриваются в следующем порядке:

      Свойства глобальных настроек Devtools в вашем домашнем каталоге (

    Чтобы указать файлы внешних свойств, эти параметры должны вас заинтересовать:

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

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

    • @PropertySource аннотации к вашим @Configuration классам. Свойства по умолчанию (задаются настройкой SpringApplication.setDefaultProperties ).

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

    Расположение по умолчанию для файлов application.properties

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

    • Подкаталог / config текущего каталога

    • Текущий каталог

    • Пакет classpath / config

    • Корень пути к классам

    Высшие приоритеты так буквально:
    classpath:/,classpath:/config/,file:./,file:./config/ .

    Как использовать файлы свойств с определенными именами?

    Места по умолчанию не всегда достаточно: места по умолчанию, такие как имя файла по умолчанию ( application.properties ), могут не подходить. Кроме того, как и в вопросе OP, вам может потребоваться указать несколько файлов конфигурации, кроме application.properties (и варианта).
    Так spring.config.name что будет мало.

    В этом случае вы должны указать точное местоположение с помощью spring.config.location свойства среды (которое представляет собой список разделенных запятыми местоположений каталогов или путей к файлам).
    Чтобы не беспокоиться о шаблоне имен файлов, предпочтите список путей к файлам списку каталогов.
    Например, вот так:

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

    spring.config.location теперь заменяет местоположения по умолчанию, а не добавляет к ним

    В Spring Boot 1 spring.config.location аргумент добавляет указанные местоположения в среду Spring.
    Но из Spring Boot 2 spring.config.location заменяет местоположения по умолчанию, используемые Spring, указанными местоположениями в среде Spring, как указано в документации .

    1. file:./custom-config/

    2. classpath:custom-config/

    spring.config.location теперь способ убедиться, что любой application.properties файл должен быть явно указан.
    Для uber JAR, которые не должны упаковывать application.properties файлы, это довольно приятно.

    Чтобы сохранить старое поведение spring.config.location при использовании Spring Boot 2, вы можете использовать новое spring.config.additional-location свойство вместо этого, spring.config.location которое по-прежнему добавляет местоположения, как указано в документации :

    В качестве альтернативы, когда настраиваемые расположения конфигурации настраиваются с помощью spring.config.additional-location , они используются в дополнение к расположениям по умолчанию.

    На практике

    Итак, предположим, что, как и в вопросе OP, у вас есть 2 файла внешних свойств для указания и 1 файл свойств, включенный в uber jar.

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