Порядок привязки декларативных сервисов OSGi

Предполагая, что я использую декларативные службы OSGi, и у меня есть служба, имеющая числовые ссылки с policy = dynamic...

A - Обязательный унарный.

B - Обязательный унарный.

C - Обязательный кратный.

D - Необязательный унарный.

E - Необязательный множественный.

Все ссылки доступны при запуске моего сервиса. Есть ли способ контролировать, в каком порядке вызывается связывание?

Я хотел бы, чтобы B связывался первым и что-то делал с каждым поступающим E, но у меня нет возможности гарантировать, что B будет связан до E.

Да, более логичным подходом было бы позволить сервису, который представляет B, также связываться с E и делать все, что он должен делать, но я не могу модифицировать B, я могу только использовать его. Если я создам новую службу, которая просто привязывается к B и E, у меня все равно будет та же проблема.

Я мог бы делать все, что мне нужно, в методе активации, когда все привязано, а затем делать это, когда связаны дополнительные (динамические) E, но мне было интересно, есть ли другой способ...


person MarcB    schedule 10.07.2013    source источник


Ответы (1)


Заставьте ссылку B использовать «статическую» политику, которая гарантирует, что она будет привязана до вызова метода активации.

Если ссылка E объявлена ​​как множественная/необязательная с «динамической» политикой — что является практически единственным разумным выбором, когда у вас есть множественная ссылка — тогда она будет привязана/несвязана всякий раз, когда сервисы публикуются/не публикуются. Это может произойти в любом потоке и даже (несколько раз!) во время вызова метода активации.

person Neil Bartlett    schedule 10.07.2013
comment
А, это сработает. Спасибо! Я предполагаю, что required_multiple в сочетании со статической политикой является одним из тех, которые никогда не используются, тогда? - person MarcB; 11.07.2013
comment
По сути да. При использовании статической политики DS придется уничтожать и воссоздавать ваш компонент каждый раз, когда служба появляется или исчезает. Фактически по этой причине он никогда не сообщит вам о новых службах, появившихся позже, если только вы не используете новую опцию жадной политики, добавленную в DS 1.2. - person Neil Bartlett; 11.07.2013
comment
Мое наблюдение за felix заключается в том, что даже когда B использует статическую политику, а E использует несколько/необязательный с динамической политикой, порядок, в котором аннотации @Reference размещаются в классе (и теги ‹reference› в дескрипторе службы) имеет значение. Если ссылка для E появляется перед B, E будет привязана первой - person mdzh; 15.12.2016
comment
@mdzh Это не противоречит тому, что я сказал: поля статической политики связываются до вызова активации. - person Neil Bartlett; 15.12.2016