Статьи Генератор паролей UUID MD5 Unix-время URL-encode Base64 Форматирование XML Ваш внешний IP Число прописью


Сравнение форматов конфига в Spring Boot

Вернуться назад

16 февраля 2020

Тэги: Spring Boot Spring Collections Java

Spring Boot позволяет хранить настройки приложения в файле и получать к ним доступ в декларативном стиле. Этот файл может иметь один из трёх форматов: properties, xml и yaml. Как Spring будет интерпретировать формат файла, определяется его расширением. Далее мы рассмотрим плюсы и минусы каждого формата. В качестве примера предположим, что в конфиге мы храним число, текстовую строку на русском языке и список значений.

properties-файл

По умолчанию в Spring используется properties-конфиг. Имя файла должно начинаться со слова application и иметь расширение properties. Если вы не используете профили для разделения конфигов, то достаточно иметь файл application.properties.

# числовой параметр
some.test.numberValue=42
# текстовый параметр
some.test.textValue="Текстовый параметр из properties-файла"
# список значений
some.test.list[0]=one
some.test.list[1]=two
some.test.list[2]=three

В данном формате комментарии всегда начинаются с новой строки и с символа «#». Имя каждого параметра прописывается полностью (и это один из недостатков данного формата), затем идёт «=», затем само значение. Текстовые значения можно указывать как в кавычках, так и без них. Список значений, который в нашем приложении превратится в объект типа List, в конце имени каждого значения имеет индекс в квадратных скобках. Такой синтаксис похож на объявление массива.

Настройки с общим префиксом (в нашем случае это «some.test») удобно группировать в одном конфигурационном бине. Для нашего примера этот бин выглядит так:

@Component
@ConfigurationProperties(prefix = "some.test")
public class MyParams {

    private int numberValue;
    private String textValue;
    private List<String> list = new ArrayList<>();

    // далее идут get- и set-методы...
}

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

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

XML

Xml-конфиг можно хранить в файле application.xml. Его достоинством является поддержка юникода. Заменим application.properties на application.xml следующего содержания:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
    <!-- числовой параметр-->
    <entry key="some.test.numberValue">42</entry>
    <!-- текстовый параметр -->
    <entry key="some.test.textValue">Текстовый параметр из xml-файла</entry>
    <!-- список текстовых значений -->
    <entry key="some.test.list[0]">one</entry>
    <entry key="some.test.list[1]">two</entry>
    <entry key="some.test.list[2]">three</entry>
</properties>

Как видите, данный формат является стандартным xml, поэтому довольно многословен. Зато более универсален.

Каждый параметр представлен элементом entry. Имя параметра задаётся атрибутом key. Список значений именуется так же, как в properties-файле.

Бин MyProperties, который мы создали ранее, будет также успешно работать и с этим форматом. И строка текста на русском будет отображаться корректно.

YAML

Наконец, рассмотрим наиболее современный формат - yaml. Он лишён многословности xml и при этом поддерживает юникод. Заменим application.xml на application.yml следующего содержания:

some:
  test:
    numberValue: 42 # числовой параметр
    textValue: Текстовый параметр из yaml-файла # текстовый параметр
    list: # список текстовых значений
      - one
      - two
      - three

Как видите, yaml наглядно демонтрирует иерархичность настроек. Часть имени параметра test является дочерней по отношению к some, поэтому располагается на другой строке и с отступом в два пробела. numberValue является дочерним по отношению к test и находится по отношению к нему с отступом в 2 пробела или в 4 пробела от начала строки.

Имя параметра всегда оканчивается двоеточием. Если на этой же строке располагается значение, то после двоеточия следует пробел, а затем само значение. Текстовые значение можно брать в кавычки. Комментарии могут располагаться в конце той же строки. Они начинаются с «#». Элементы списка всегда начинаются с тире, затем идёт пробел, затем само значение.

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

Сравнение

ФорматПлюсыМинусы
propertiesПредлагается по умолчанию. Прост в использовании.Многословен. Не поддерживает юникод.
xmlПоддерживает юникод.Крайне многословен.
yamlПоддерживает юникод. Компактный и наглядный формат.Требует знания правил форматирования.