Сервисные трекеры OSGi не всегда работают - PullRequest
0 голосов
/ 01 июля 2010

Привет, ребята. Мы используем сервисы OSGi в приложении Eclipse RCP. Для их отслеживания мы используем класс org.osgi.util.tracker.ServiceTracker. Пример кода из приложения выглядит как

mailServiceTracker = new ServiceTracker(context, MailService.class.getName(), null);
mailServiceTracker.open();
MailService service = (MailService) mailServiceTracker.getService();

Теперь моя проблема в том, что метод getService() часто возвращает null, когда я создал новый сервис. Код работает очень хорошо для сервисов, которые долгое время существуют в приложении, но каждый раз, когда я создаю новый сервис, мне приходится делать много вещей, пока сервис не будет наконец найден и отслежен. Я регулярно пробую например

  • «Чисто ...» в Eclipse
  • Обновить все проекты в Eclipse
  • Перестройка проекта из командной строки

Иногда эти вещи помогают, а иногда нет. Кто-нибудь имеет опыт работы с этими трекерами и может сказать мне, как избежать такого поведения и как отслеживать сервисы сразу после создания?

Спасибо

Ответы [ 3 ]

2 голосов
/ 21 июля 2010

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

Или вы можете просто переключиться на Декларативные услуги, которые справятся с этим для вас.

1 голос
/ 02 июля 2010

Нет ничего плохого в использовании ServiceTrackers, кроме того факта, что это довольно низкоуровневый способ отслеживания сервисов.Хотя я согласен с тем, что декларативные сервисы являются хорошим механизмом, простое увольнение ServiceTrackers из-за «всевозможных проблем» звучит как плохой совет.

Вернуться к вопросу.

Как только сервис-трекерсоздается и открывается, он дает вам доступ ко всем службам, которые соответствуют условиям фильтра, которые вы указали при создании.Там нет задержки там.Единственное, о чем я могу думать, это то, что ваши пакеты каким-то образом не разрешены правильно, поэтому сервисы, которые зарегистрированы из пакета A, просто не видны для пакета B с помощью ServiceTracker.Чтобы проверить это, сначала найдите пакет, который экспортирует пакет, содержащий интерфейс службы, а затем убедитесь, что к нему действительно подключены A и B.

Немного объясняя механизм обновления / обновления в OSGiподробнее:

Всякий раз, когда вы обновляете что-то в OSGi, это двухэтапный процесс.

Предположим, вы обновляете пакет, содержащий новую версию экспортируемого пакета.Давайте также предположим, что есть какой-то потребитель, который его импортирует.До тех пор, пока вы только обновляете пакет, но не обновляете явно проводку (из которой импортируются ссылки, а какой экспортируется), потребитель будет по-прежнему подключен к старой версии пакета.Как только вы выполните обновление пакета (то, что вы можете сделать в OSGi через службу PackageAdmin), ваш потребитель снова будет разрешен и подключен к новой версии.

Причина, по которой это не связано, заключается в том, что вы можетеВы хотите обновлять несколько пакетов, а не «обновлять» после каждого, а вместо этого откладывать такое обновление до тех пор, пока все они не будут обновлены.

Вполне возможно, что это тот эффект, который вы видите.Первоначально вы только делаете обновление, и только после обновления трекер действительно увидит новую версию сервиса.

0 голосов
/ 02 июля 2010

Не быть легкомысленным, не используйте сервисные трекеры.Похоже, они делают вашу жизнь простой, но с ними возникают разные проблемы.Я бы порекомендовал вам вместо этого использовать декларативные услуги.Поддержка DS в Eclipse была очень хорошей, начиная с 3.5.

Возможно, вы захотите проверить эту книгу и связанные с ней презентации для получения дополнительной информации о том, почему использование сервисных трекеров - плохая идея.*http://equinoxosgi.org/

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...