Сотни разных настроек, которые зависят от окружения? Ну как-то это много.

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

Не помню точно, что там написано, но мне кажется главным чтобы эти настройки были переопределяемы через переменные окружения.
Не вижу ничего плохого в том, чтобы забить в файл настройки, которые не будут меняться никогда.
Или вы spring.application.name тоже хотите в переменные окружения засунуть?

+ за @ConditionalOnProperty, намного удобнее профилей

Не хотим, у “нас” сервисы на голой JDK, и у них конфигурационные файлы очень велики. И нет настроек, которые не меняются. 🙂
И многие настройки с авто-релоадом. Есть и настройки в окружении, например, где взять файл конфигурации.
В общем, я настройки менеджю целым файлом: например, если для теста надо изменить настройку, то 2 варианта у меня: файл конфигурации конструируется тестовым фреймворком целиком и подается на вход приложению. Либо, для интеграций, через автотестовую магию меняются конкретные строки в файле на месте через SSH.

если у вас много настроек с необходимостью авторелоада, то может эти все настройки вынести в отдельный конфигурационный сервис ?

Я только за. но легаси, маленькая команда, много продуктов, много внутренних заказчиков. В общем, “не сегодня”, ибо у моего непосредственного менеджмента нет политической силы почему-то. Есть и гораздо жестче производственные проблемы, чем конфигурация, с которой проблем то особо и нет - работает и ладненько.
В общем, тред не обо мне 🙂
Просто поинтересовался про 12факторную систему по вашей ссылке. Классная тема. Спасибо

вам уже посоветовали

но лучшая практика - отдельные КОНКРЕТНЫЕ настройки + conditional бины

@dmsol мне кажется ты писал что сваггер сильно тормозит запуск спринг бут приложения ?

в чате kotlin jvm

Ребят, привет! В последнее время начал почему-то думать, что такой код плохой

private void someMethod(String someText) {
   someView.setOnClickListener(v -> {
       someAnotherMethod(someText);
   });
}

не обязательно именно так, но суть вы поняли - любой кейс, где какая-то переменная находится вне анонимного класса.
Скажите, надо ли такого кода избегать? Ну например делать вот так

private void someMethod(String someText) {
   someView.setTag(someText);
   someView.setOnClickListener(v -> {
       someAnotherMethod((String) v.getTag());
   });
}

Есть ли в этом вообще смысл? Чем плох и плох ли? Что посоветуете переучить/перечитать чтобы разобраться?

ну так все правильно, если запятая == или

выходит dev != test == true


PS похоже уже ответили)

часть в статический конфиг часть нет)

нельзя ж всему следовать слепо)

Кощунство! Дяди в инетах всегда знают лучше. StackOverflow, как пример)

когда следуешь всем советам "гуру" не помня главнй принцип "гуру" постарше (kiss)

это хело типа fizzbuzz )