1119 читателей, 672 поста
Администрация
Модераторы
Подкасты на Хабрахабре.
The Art Of Programming — Выпуск №25 / Как готовить OSGi
+ Суровые программисты
+ OSGi
+ Eclipse Rich Client Platform http://www.ozon.ru/context/detail/id/3668952/
П.С. Контакты Павла
beq
http://twitter.com/samolisov
http://samolisov.blogspot.com
П.П.С. Контакты ведущих
http://twitter.com/golodnyj
http://twitter.com/gAmUssA
http://juick.com/golodnyj/
http://juick.com/gAmUssA/ прослушан 603 раза
+ OSGi
+ Eclipse Rich Client Platform http://www.ozon.ru/context/detail/id/3668952/
П.С. Контакты Павла
beq
http://twitter.com/samolisov
http://samolisov.blogspot.com
П.П.С. Контакты ведущих
http://twitter.com/golodnyj
http://twitter.com/gAmUssA
http://juick.com/golodnyj/
http://juick.com/gAmUssA/ прослушан 603 раза
комментарии (19)
эх забыли про такой кейс +)
Предлагаю в следующий раз общаться с большей экспрессией и задавать побольше каверзных вопросов.
Кстати у меня есть немного простых вопросов:)
1. Что за OSGi шину вы используете? Сами писали или взяли готовое решение? Если взяли готовое решение, то что пришлось дорабатывать напильником? (возможно я прослушал этот момент:))
2. Сколько ресурсов кушает OSGi, особенно когда используется динамическая подгрузка модулей? Есть ли проблемы OutOfMemory?
3. Как вы масштабируете OSGi приложения? Покупаете более мощное железо или кластеризуете ваши приложения?
4. Есть ли опыт кластеризации OSGi приложений с динамической подгрузкой модулей?
5. Почему не стоит использовать OSGi? Или OSGi «серебряная пуля» для всего?
6. Как в вашей дмс с легаси кодом дела обстоят?
7. Если вы используете Hibernate для работы с БД, то что вы используете: аннотации в модели или описываете модель в xml конфигах? (просто интересно:))
8. Что вы используете для построения интерфейса пользователя? (просто интересно:))
p/s
Забыл передать привет городу Челябинску и всем суровым программистам оттуда:) Я мог быть среди вас:)
1. Мы используем Equinox, единственное — стартуем его самостоятельно, т.к. Tomcat не имеет встроенной поддержки Equinox (да и OSGi вообще)
2. У нас в Naumen Kernel такая фича, как динамическая подгрузка бандлов не используется. Мы слегка расширили манифесты и нужные бандлы стартуют в указанном порядке. Я не знаю, почему было принято такое решение, но скорее всего это связано с самостоятельным управлением ЖЦ бандла (см. ответ на 1-й вопрос). Если вы пользуетесь Eclipse, то можете замерить сколько раз у вас было OutOfMemory, у меня пока ни разу.
3. Мы плотно работаем над улучшение производительности нашего приложения, но если упираемся во что-то, то покупаем более мощное железо.
4. Нет, такой опыт отсутствует.
5. С OSGi конечно тоже могут быть проблемы. Во-первых его не следует использовать, если вы не строите расширяемое приложение. Во-вторых, если у вас планируется 2-3 плагина или вы пишите для десктопа что-то маленькое (лишние 800к могут быть критичными). В остальных случаях — OSGi может быть удачным выбором. Но! Надо четко продумать стратегию управления ЖЦ бандлов, в частности кто, когда и какие бандлы будет стартовать.
6. ДМС разрабатывается как «наследник» системы NauDoc, которая была написана на Python. Поэтому легаси кода, как такового нет. Если «легаси-решения», которые переписаны на java.
7. Да, мы используем Hibernate, модель описываем xml. Дело в том, что разработка платформы началась еще во времена JDK 1.4 когда и аннотаций то не было.
8. Для построения веб-интерфейса мы используем свой фреймворк. Особенностью нашей системы является то, что нет настраиваемых/сменяемых дизайнов (не сайты же делаем), поэтому мы отошли от концепции страниц и перешли к концепции объектов. Т.е. отображаемой единицей является объет, который естественно имеет класс, а класс имеет паблишер — xml-файл, описывающие его отображения. Ну и там же все формы, кнопки и т.д. В xml манипулируем компонентами, каждый компонент имеет jsp-файл, который описывает генерацию html для этого компонента. JSP-шки мы прекомпилируем в .class-файлы до деплоя приложения.
Продолжим?;)
2. А в какой области вы расширили манифесты? Чего не хватило в стандартном OSGi?
3. Интересно было бы знать нагрузку на сервер. Сколько у вас одновременно работающих пользователей?
Кстати я немного слукавил, с вашей системой (наумен кернел) мне уже приходилось сталкиваться два года назад. Судя по всему у вас больших изменений так и не случилось:) Зато стабильность наверно возросла в разы:)
Во-вторых, добавили параметры start-before и start-after для явного указания порядка запуска и зависимостей.
А масштабируемость и OSGi вообще перпендикулярны. OSGi не помогает и не мешает.
Интересно было бы услышать про хаки в класслоадерах:)
p/s
Я не сильно наглею?:)
А про хаки… Там все просто. Сделали, например, classloader, который видит вообще все содержимое всех бандлов, независимо от того, какие пакеты они экспортируют. Этот classloader используется хибернейтом, компилятором groovy, [де]сериализатором и т.п. библиотеками. Хак, конечно, но удобно.
И еще пришлось вручную добавлять кэш результатов поиска пакетов: при загрузке классов equinox может очень долго искать бандл, содержащий нужный пакет.
Еще какие-то мелочи сделали, но я уже не помню, какие.
2. На сколько мне известно все таки есть моменты в osgi/equinox, которые доставляют определенные проблемы, можете рассказать об этом?
2. Момент, по сути, всего один — osgi был не самым удачным выбором:) Это контейнер для относительно независимых модулей, которые друг о друге не знают и друг другу не доверяют. Если же пилить одно большое приложение на мелкие osgi-бандлы, то возникает сразу куча проблем и неиспользуемых фич.
Во-первых, загрузка классов. Если положить hibernate в один бандл, а бизнес-логику — в другой, то hibernate без особой магии не сможет загружать классы из другого бандла. То же самое для всех библиотек, использующих загрузку классов по имени.
Во-вторых, обновление модулей «на ходу» и прочяя динамика. Они совсем не пригодились. Даже если обновляется только один модуль, то нужно останавливать работу с БД, завершать все выполняющиеся HTTP-запросы и фоновые процессы, выполнять миграции схемы БД, заставлять все библиотеки (тот же hibernate) перечитывать конфигурацию. В общем, downtime неизбежен, и проще перезапускать приложение целиком, чем реализовывать всю эту логику.
В-третьих, активация бандлов в произвольном порядке. Это сильно усложняет логику инициализации. Например, задача переопределения кусочка GUI, определенного в другом бандле, становится весьма нетривиальной: во время активации приходится собирать из всех бандлов все описания GUI и после сортировать их по зависимостям.
В-четвертых, ручной импорт-экспорт пакетов. Опечатки в длинных списках пакетов моментально сносили приложению крышу. При этом такая детализация была попросту не нужна. Проще оказалось работать не с отдельными пакетами, а с целыми бандлами.
В-пятых, пришлось отломать кэш бандлов (это такая штука, в которой живут локальные копии бандлов, распакованные и подготовленные equinox-ом к запуску). До этого equinox при запуске стирал кэш и распаковывал туда заново весь код и ресурсы. Иногда у него что-то шло не так, в кэше оставался старый код и приложению опять-таки срывало крышу. В production, при выкладке критичного обновления.
Могу еще много всего вспомнить:)
Просто я тоже учавствовал в разработке веб-фреймворка где была динамическая подгрузка модулей. Решение добавить динамику привело к усложнению поддержки, да и в итоге все выродилось в: выложил новый модуль, перезапустил сервер приложений:)
А так реально получилось osgi для блондинок какой-то.
для начала так сказать +)