Pull to refresh

Comments 16

Спасибо. Жаль, что не довелось ещё поиспользовать — выглядит красиво и, главное, заставляет делать проекты модульными.
А вы попробуйте. Для начала на тестовом проекте, а потом, возможно, и в production. Чем более популярна будет технология, тем активней будет развиваться.
Я б с радостью. Да только в ближайшие пару лет совершенно в другой области работать буду.
Неплохая связка, мы используем в своем проекте. Интересно было бы узнать кто её применяет и в каких проектах.
На данный момент я разрабатываю свой хобби-проект на базе Eclipse Virgo. Это будет набор приложений для совместной работы над проектами (преимущественно разработкой ПО). Выбор был сделан в пользу данной связки, дабы не изобретать свой плагинный движок. А в каком проекте вы используете Spring и OSGi?
production, довольно крупный проект
Не расскажете поподробнее, например, нету ли проблем с разрешением зависимостей?
Можете привести реальный пример использования? Из своего опыта.
Веб-приложение с плагинной системой см. выше.
Если не сложно, опишите конкретные задачи, которые вы предполагаете решать с помощью OSGi и приемущества перед стандартным подходом.
Приложение формирует пользовательское окружение на основе сервисов, которые зарегистрированы в контейнере. Например: в некую абстракция рабочей области встраивается возможность доступа к wiki-движку, и системе управления взаимодействием. Каждая из подсистем представляется в виде сервиса.
Спасибо за обзор. Думаю использовать Spring DM в следующем проекте, однако в специфику пока не вникал. Посему есть несколько неясностей. Буду признателен, если проясните. Пусть модуль P предоставляет некий сервис с интерфейсом I и несколько связанных с ним структур данных, а модуль C его собирается использовать.

1. Как передаются параметры при вызове от модуля к модулю: по значению (сериализация-десериализация), или по ссылке?
2. Как происходит резольвинг классов между модулями? Насколько я понимаю, каждый модуль имеет свой ClassLoader. И насколько я понимаю, delegation между ними не используется. Иначе когда модуль P недоступен, С не смог бы сделать резольвинг интерфейса I. То есть модуль C использует непосредственно классы из P или имеет собственную копию exported-пакетов?
3. А что будет если мы внезапно запустили новую версию сервиса P, которая поменяла интерфейс I и несколько экспортнутых классов? Если передача параметров идет по значению, то проблем не должно быть если классы остались serializable-совместимыми. Если же по ссылке, то возникнет ClassCastException, т.к. модуль C уже отрезольвил старую версию классов.
4. Я слышал, что можно одновременно иметь несколько версий одного и того же сервиса. И что consumer будет использовать именно последнюю версию сервиса. Можно ли как-нибудь динамически контролировать какую версию сервиса использовать?
5. Чтобы сделать unit-тесты для сервисов без испльзования OSGi, как я понимаю, очень несложно. Для этого нужно прописать соответствующие сервисы в тестовом spring context. А как делать автоматические integration-тесты в OSGi-контейнере? Есть какая-нибудь тулза?
1. Параметры передаются также, как и в обычной Java программе.
2. Резольвинг происходит согласно правилам import и export. Т.е. ClassLoader модуля связан с фреймворком и знает какие классы доступны через export у других модулей, и знает какие сделать доступными текущиму модулю из import.
3. После изменения кода интерфейсов и классов необходимо выполнить операцию refresh на всех модулях, которые использовали их.
4. Возможно указывать правила фильтров, какие версии сервисов использовать. Можно получать целую коллекцию сервисов с заданными интерфейсами и выбирать необходимы сервис. При это коллекция будет при каждом обращении соответствовать актуальному набору сервисов, которые присутствуют в текущий момент.
5. Spring dm и Gemini Blueprint поддерживают модульное тестирования и имеют специальные классы для поднятия OSGi окружения при тестировании в jUnit. Смотрите Testing OSGi based Applications.
Думаю, что на почти на все вопросы ответит OSGi спецификация OSGi Spec 4.2 Чтобы не копировать — вот ссылки:
2. OSGi Spec 4.2 Core: 3.4. Class Loading Architecture, 3.7. Resolving Process, 3.8. Runtime Class Loading
3&4. OSGi Spec 4.2 Core: 5. Service Layer
5. Pax-Exam — OSGi Unit tests framework

Спасибо, статью в закладки.
В одном проекте использовали связку Spring и OSGI (Equinox), все довольно удачно получилось, но столкнулись с проблемой, что со спрингом был лишь один модуль, так как больше одного спрингового контекста было почему-то не поднять. У вас как я вижу такая проблема отсутствует. Еще раз спасибо за статью, возьму на заметку.
Sign up to leave a comment.

Articles