LINUX.ORG.RU

Spring - правильный способ создания бинов, требующих длительной инициализации

 , ,


0

2

Фыр, чат.

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

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



Последнее исправление: bo4ok (всего исправлений: 1)

Ответ на: комментарий от maxcom

По замыслу дизайнера, экран загрузки рисует статусы инициализации этих подсистем, так что они являются его логическими зависимостями х)

Понятно, что кейс простой и можно выкрутиться, интересует более общее решение

bo4ok
() автор топика
Ответ на: комментарий от bo4ok

Мне кажется эта идея противоестейственной. Лучше завести какой-то канал в обратную сторону (веб-сокеты или SSE) и кидать в него сообщения по мере инициализации. А инициализацию сделать просто ленивой без какой-то асинхронной логики.

maxcom ★★★★★
()

Развести инициализацию бинов и выполнение длительных операций. Внутри бина трекать это разными состояниями (создан -> подключен к железке -> тестирую железку -> калибрую -> работаю в штатном режиме) и в зависимости от текущего состояния показывать ту или иную информацию на webui.

Ещё стоит подумать о ситуации недоступности железки при старте, и её доступности позднее. Подход с выделенными состояниями бина и асинхронными переходами между ними позволит и такой случай отработать.

Begemoth ★★★★★
()