Comments 6
Интересная статья, некоторые подходы схожи с тем, что я использовал здесь и здесь, я имею ввиду использование актуатора
https://habr.com/ru/company/otus/blog/681214/
https://habr.com/ru/company/otus/blog/682594/
Очень хотелось бы увидеть продолжение, вариант автообновления, выполненный на Spring Cloud Bus с Kafka, было бы здорово. Полагаю, что для тысяч клиентов уже было бы затруднительно без этого обойтись.
В методах refresh() сначала идет вызов init(), а потом destroy() - разве не наоборот должно быть?
Тут нужно ещё не забывать про гонки сигналов, когда один компонент обновился, а др ещё нет. Приведёт ли это к проблемам или нет конкретно в вашем приложении... Но естественно, универсального решения нет (кроме пушки в виде кубера, но это наверное зачастую слишком крупно-калиберная пушка и не всем подходит..., а может и нет, статистикой не обладаю)
Да, я с Вами согласен, возможно в будущем придется поддержать что-то типа@DependsOn,пока для начала, для решения текущих задач мне достаточно такой реализации, в процессе эксплуатации данного подход возможно понадобится дополнить функциональность постпроцессора. Как я упомянул в статье, сначала вообще хотелось сделать какую-то универсальную выгрузку и загрузку бина из контекста по этому событию, но немного погрузившись понял, что много чего нужно учесть и вряд ли это будет "универсально". Так что за полной универсальностью не гонюсь, будем решать проблемы по мере поступления. В любом случае, даже используя стандартные библиотеки springa все равно надо понимать как это работает, как и в случае с моим постпроцессором, чтобы понимать правильно ли работает разработанное приложение.
Про крупно-калиберную пушку не понял:)
Spring Cloud Config и обновление компонентов в рантайме