Понимание конфигурации входа по умолчанию в Spring Boot 2 - PullRequest
Новая
       33

Понимание конфигурации входа по умолчанию в Spring Boot 2

0 голосов
/ 26 марта 2019

Я создаю приложение Java Spring Boot 2.1, которое использует Maven для добавления зависимости spring-boot-starter. Как написано в документации , это разрешает конфигурацию обратного входа по умолчанию. Эту конфигурацию можно найти свободно в этом репозитории и содержит синтаксис, который мне немного сложен для понимания.

1. Таинственный рывок

Я знаю, что свойства Spring устанавливаются с использованием следующего синтаксиса

$ {property.name:someDefaultValue}

Однако в файлах xml для конфигурации обратного входа всегда есть тире сразу после двоеточия. Почему это? например:

<имя свойства = "LOG_FILE" value = "$ {LOG_FILE: - $ {LOG_PATH: - $ {LOG_TEMP: - $ {java.io.tmpdir: - / tmp}}} / spring.log} />"

2. Изменяющиеся имена свойств

Мне также неясно, откуда все эти названия свойств. В документации упоминается заполнение наших application.properties или application.yml такими свойствами, как:

logging.file = /app/logs/mylog.log

Как и где свойство с именем logging.file преобразуется в свойство с именем LOG_FILE, используемое в xml-файле logback?

3. Недостающее имущество

В частности, это свойство не имеет эквивалентного свойства в application.properties (или .yml) для его настройки

$ {LOG_FILE_TOTAL_SIZE_CAP: -0}

Если я хочу изменить это свойство на какое-то другое значение, мне придется каким-то образом установить свойство LOG_FILE_TOTAL_SIZE_CAP. Как я могу сделать это, все еще используя исходную конфигурацию xml по умолчанию для logback, предоставляемую весенней загрузкой?

4. Мы застряли с добавками по умолчанию

Единственная логика appender в файлах XML logback:

И application.properties не позволяют изменить это. Хотя я должен признать, что это очень полезное значение по умолчанию, иногда оно не работает. Кажется чрезмерным, что нужно полностью перезаписать всю конфигурацию xml logback для одного небольшого изменения в appender или policy. Если бы я предоставил несколько пользовательских файлов конфигурации logback / xml на моем пути к классам, logback «слил бы» их или просто выбрал бы один и проигнорировал другие? Как работает перезапись / слияние, какой xml «выигрывает»?

1 Ответ

1 голос
/ 26 марта 2019

1.Таинственный тире

Для входа в систему: https://logback.qos.ch/manual/configuration.html. В частности:

При определенных обстоятельствах желательно, чтобы переменная имела значение по умолчанию, если онане объявлено или его значение равно нулю.Как и в оболочке Bash, значения по умолчанию можно указать с помощью оператора «: -».Например, если переменная с именем aName не определена, «$ {aName: -golden}» будет интерпретироваться как «золотой».

2.Изменяющиеся имена свойств

Это должно помочь с сопоставлениями: https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-logging.html. Также вы можете просмотреть org.springframework.boot.logging.LoggingSystemProperties.

3.Недостающее имущество

Я согласен с вашей оценкой!Может быть, здесь поможет кое-что покопаться в LoggingSystemProperties (в методе apply()?).Но более вероятно, что проблема будет решена путем предоставления собственного logback.xml.

4.Мы застряли с добавками по умолчанию

Это тоже правда.См. 83.1 из https://docs.spring.io/spring-boot/docs/current/reference/html/howto-logging.html. Практически каждый проект, с которым я когда-либо работал, имел собственный log4j.xml, logback.xml и т. Д.

...