Нет, самое страшное это OSGi

Оу, Спасибо
А как свой добавить?)

Или хоть в какую сторону копать

О, мы сначала думали его использовать
Чем он плох?

Зачем? Там вроде authentication service свой надо передать, насколько помню

Благодарю🙏🏻

Во первых он не нужен когда уже есть микросервисы. Это точно

Во вторых он стар, ужасен, имеет достаточно проблем

Вот какую задачу/проблему вы пытаетесь решить использованием osgi?

У нас был проект на верблюде поверх караф с его менеджером транзакций (другие кроме одного не заводится) - самое ужасное, что я делал

Больше всего гавна я поймал именно на этом проекте

У нас может быть много мест, откуда нужно читать, и много мест, куда нужно писать
Это и InfluxBD, и OPC протокол (который с промышленными аппаратами работает), и еще много всякого
Руководство хочет, чтобы эти драйвера условные можно было писать самим заказчикам
Мы протестили с микросервисами - получилось слишком долго
Нам нужно там до 3к значений прочитывать за пару секунд, а с микросервисами дольше получается (а это мы еще не перенесли из старого проекта вычисления параметров)
Сейчас я написал загрузку jar-ников изолированным класслоадером

З.Ы. DI на сервис локаторе это буэ

Получается, что приходится обмазываться reflection, потому что один класс, загруженный разными класслоадерами - это разные классы
Но зато по простому бенчмарку, который мы сделали - в 70 раз быстрее

Осги не прибавит скорость обработки)

Что чего быстрее?

Что было и как стало?

@kuzznya можешь завтра расписать, либо сейчас, я пока что точно спать

Загружать джарники URLClassLoader'ом и взаимодействовать с ними относительно подхода "драйвер как микросервис"
(Тут естественно, потому что это всё тогда в одной JVM происходит)

А как взаимодействуете между микросервисами?

Не говори рест