Могу ли я вводить прокси-серверы перед службами Blueprint, опубликованными другими пакетами?

Question

Мы используем Karaf и ряд OSGI Blueprint services для реализации системы.

Можно ли сделать "BundleListener" тип расслоения, когда присутствует в OSGI контейнере, украшает наш Blueprint services с прокси так расслоений со ссылкой эти услуги будут называть прокси вместо этого?

(я думаю, это может быть достигнуто либо путем каким-то образом добавляя прокси перед службой уже в реестре службы, либо путем изменения ссылку, полученную ссылающейся пачке - ServiceTracker.addingService стиль)

Answer 1

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

Существующее:

+----------+    +----------+ 
    | register |------<|------| using | 
    +----------+    +----------+ 

через прокси

+----------+   hide +----------+ 
    | register |------<|-+--X-| using |---|>---+ proxied 
    +----------+   | +----------+  | 
         |      | 
         | +----------+  | 
         +----| manager |--------+ 
          +----------+ 

Хотя сначала немного странно, эта возможность «удалить из поля зрения» позволяет управлять в деталях, что сервис пучок подвергается воздействию, сохраняя при этом общая сложность минимальна. См. Главу 55 в ядре OSGi 5.0.0. В разделе 55.3.1 указан этот прокси.

<soapbox>

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

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

Используя свойство/другой тип для прокси

+----------+    +----------+ proxied=true 
    | register |    | using |---|>---+ 
    +----------+    +----------+  | 
     |          | 
     |     +----------+  | 
     +-----------<|------| manager |--------+ 
          +----------+ 

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

Если вы используете Declarative Services (DS), то вам повезло! С помощью DS вы можете установить фильтр по служебной ссылке через Configuration Admin с помощью «target». свойство конфигурации. Таким образом, диспетчерский узел видит, что служба должна быть проксирована, она регистрирует вторую услугу со специальным свойством (например, «proxied = true»). Затем с помощью пакета устанавливается фильтр, заданный целевым ссылочным свойством Configuration Admin DS, например '(proxied = *)'.

</soapbox>

Answer 2

Хотя не реализована в качестве прокси, копирку перехватчик может делать то, что вы хотите; вы можете перехватывать вызовы метода до или после вызова исходного компонента. Я предполагаю, что это то, что вы будете делать с вашим прокси-сервером в любом случае. Реализация Овна Blueprint в Karaf должна определенно поддерживать перехватчики. Однако я не могу найти хорошую документацию или примеры вне самого источника Овна, что делает этот ответ менее полезным, чем я надеялся!