Comments 23
У меня тоже был опыт работы с OSGI. Например Spring поддерживается версии 3 - это 2010 год. То есть на технологию забили уже 14 лет. Ни одна современная бибилотека не поддерживает OSGI. Попытка что-то использовать выливается в перманентное сражение, и не факт что успешное. Да и OSGI, по моему мнению, стоит рассматривать как динамические сервисы И написание бандлов и вообще использование этой технологии стоит рассматривать именно так. Если у вас нет динамики - оно вам не нужно. А с учетом того, что сейчас бал правят микросервисы и даже application server - уже тоже не в почете, то что говорить о OSGI.
Поэтому перед использованием, следует не 10 а 1000 раз подумать, и выбрать что-то другое.
Karaf OSGi Runtime 4.4.5
January 10, 2024
Сказать что технология активно развивается - конечно соврать. Но "забили" в ситуации, когда последний релиз был вот только что - тоже соврать.
Судя по тому, что вы говорите про Karaf, вы не знаете что такое OSGI, как оно работает, и что я имел ввиду, говоря про его поддержку.
Разъясняю: Karaf - это ядро/движок. К нему нужны бандлы, без них он никому не нужен. А бандлы перестали делать как раз, наверное, в году 2010.
Евли у вас все самописное, как например Eclipse, то все прекрасно. А если вам нужно что-то из современных библиотек и технологий - то тут все печально.
в плане небиблиотечных зависимостей можно посмотреть как сделаны сервисы в Liferay. Мне показалось очень крутой возможность переопределять любые сервисы ядра без патчинга и "плагинов" и межмодульное взаимодействие как при использовании локального контекста.
Автор, а зачем вы берете Felix в чистом виде? Есть же Karaf и Fuse. И ServiceMix. Там все сильно удобнее. Или я вас не так понял?
Я хоть OSGI и не трогал, но всегда думал, что это технология для изоляции нескольких программных модулей в рамках одной JVM. Т.е. можно, например, использовать разные несовместимые версии одной и той же библиотеки в разных модулях и это не сломается. Как бы вы организовали такое без OSGI? Shading?
Верно, краеугольный камень OSGi - свой загрузчик классов для каждого 'модуля'.
Поэтому, даже одноименные классы из разных модулей - это разный код в JVM.
И, приложение, реализованное на базе OSGi - проще конструировать/сопровождать, чем в концепции JAR hell, пусть, даже с использованием модулей Java.
OSGi не так прост, как кажется.
Стандарт OSGi настолько широк, что включает, например, спецификацию XML парсера...
А вот, короткая статья про ECF, реализацию спецификации удаленных OSGi-сервисов:
http://samolisov.blogspot.com/2011/06/eclipse-indigo-ecf.html
OSGi, говорят, использовался для создания встроенных систем (в частности, для автомобилей BMW).
Если интересно - посмотрите перевод книги "OSGi and Equinox. Creating Highly Modular Java Systems". http://vfedorov.info:7070/OSGiEquinox/
В ней, в качестве примера - приложение GPS трекера.
wiki книги спросит пользователь/пароль, соответственно ответить: anybody/123123
А разве микроядра - это не про операционки?
Нет, это architecture patterns.
Вы точно понимаете о чем пишете?
Я думаю, что да. Могу предложить исследовать статью oreilly, посвещенную этому вопросу, https://www.oreilly.com/content/software-architecture-patterns/. В статье представлен общий экскурс в architecture patterns. Надеюсь, что вы считаете это издание достаточно авторитетным.
Для тех кто живёт в экосистеме Spring выглядит попроще. Встроенный loader позволяет подгрузить любые джарки в класс пасс, главное собрать fat jar. Конечно не в рантайме но если это не нужно то это кажется самый оптимальный способ.
Сегодня такое можно сделать не прибегая к сторонним фреймворкам. Java SDK позволяет построить модульный проект с изоляцией модулей на уровне загрузчиков классов и с динамической загрузкой/выгрузкой.
Я не уверен, что это возможно. Проект Jigsaw, к которому вы вероятнее всего отсылаете, про изоляцию модулей, которая не позволяет решить проблему одновременного использования зависимостей разных версий. Например, использовать Guava разных версий в разных частях проекта.
Возможно, что я ошибаюсь и у вас получится собрать контрпример.
Что вы понимаете под разными частями проекта? Если эти части возможно выделить в отдельные модули и загрузить паралельно, то вполне себе возможно использовать разные версии guava в них.
Если интересно то советую посмотреть доклад Липского https://youtu.be/aw6YJLJG5hw?si=F0qDmPZivPw63-c1
В нем он кстати приводит недостатки OSGI.
Я уже делал подобную систему на Jigsaw и это работает.
В процессе исследований я обратил внимание на доклад Липского, но у меня не получилось на основе этой технологии реализовать одновременное использование разных версий guava в разных сервисах.
Root Service
||
||====> Service A ===> Guava 10.0
||
||====> Service B ===> Guava 33.1.0-jre Если вдруг у вас получилось с помощью Jigsaw это реализовать, пожалуйста, подскажите пример демо проекта / статьи с описанием реализации.
Заставлять нас искать кусок про OSGI в довольно длинном видео - это садизм :)
Можете примерно сказать, на какой минуте про OSGI? Все прочие доклады что я видел на эту тему, страдали тем, что авторы не понимали OSGI с практической стороны, т.е. никогда не использовали в жизни. Чистые теоретики.
Извиняюсь. У него есть отдельный доклад на эту тему
https://www.youtube.com/watch?v=E3A6Z02TIjg можно смотреть с 14:06
Вопрос не в том, прибегая или нет. Вопрос скорее в том, как проще. И ответ на него не всегда одинаковый. Скажем, я не встречал тех проблем, что автор тут описывает, зато например split package, когда один пакет определен в двух разных jar, это как правило геморрой с гарантией.
Но в большинстве классических случае использования зависимостей (и конфликтов в процессе) в OSGI контейнере выглядит как-то примерно так (у меня опыт работы с чистым karaf. Fuse и ServiceMix, они все основаны на карафе же):
загружаем в контейнер очередной наш модуль
выясняем, что он не стартует, потому что зависимости не разрешились - нет каких-то пакетов
выясняем, откуда эти пакеты
устанавливаем зависимости прямо из репозитория maven
обновляем наш компонент
И при этом нам как правило до лампочки, что одному нашему модулю нужна guava другой версии - мы их все можем загрузить.
То есть, по сути это выглядит как добавление зависимостей при сборке проекта в pom.xml или чем мы там собираем - только в рантайме.
Безусловно все зависит от задач, но проекты на OSGI (в частности Apache Karaf) – это для неповоротливых монолитов, которые не перезапускаются месяцами, когда для деплоя мы подключаемся к консоли по ssh и выгружаем / загружаем модули вручную, когда перенос данных со стенда на стенд – это испытания и боль, когда отладка – это бессонные ночи. В современном мире с ci/cd, с kubernetes и микросервисами использовать Karaf – это боль. Говорю по собственному опыту. Но как упомянул все зависит от проекта, интересно узнать, что вас сподвигло на использование этого подхода?
У нас точно такая же нога, и не болит (с).
Не вижу причин, почему не использовать, если все что вы описываете, к нам неприменимо? Вас смущает отсутствие перезагрузки месяцами - а как по мне, это признак стабильности. Что в этом плохого-то, особенно в ситуации, когда бандлы можно перезагрузить на лету?
Я вполне понимаю, что ваши проекты хорошо ложатся не k8s, ну так и замечательно. Это ничего практически не говорит о карафе, кроме того, что для ваших проектов k8s лучше. Я могу даже сказать, что караф довольно туго масштабируется - мы вот пробовали cellar, я бы не стал его рекомендовать. Т.е. если вам нужно динамически расширяться - да, караф не ваш выбор, но у нас расширение предсказуемо скажем за месяц, я даже статически могу еще узел развернуть, и руками его подключить, даже без всякой автоматизации успею. А так-то у меня все через дженкинс сделано.
Упоминание же микросервисов меня вообще смутило. Для меня бандл это и есть микросервис. Понятно что не любой, я не могу написать бандл на Go. Но мне это и не нужно.
Возможно все ваши боли, или значительная их часть - от того, что вы не сами технологию выбрали, а вам она досталась, и была непривычной?
Реализации Microkernel архитектуры с помощью Java OSGI