Недостающая зависимость OSGi диагностического компонента

Во время разработки мы склонны разбивать наши декларативные сервисные компоненты, поэтому OSGi, естественно, не активирует другие зависимые компоненты. Есть ли способ диагностировать основную проблему, т.е. «почему компонент не активирован?»Недостающая зависимость OSGi диагностического компонента

Для простого графа зависимостей:

A------>B------>C------->E 
       ^
       | 
     D-------+

Когда E не может быть активированы все зависимые компоненты, C, D, B, A не активируется, а также. Мне нужна консольная команда, чтобы спросить «почему A не активирован?» и ответ будет содержать ответ: «A зависит от B, B зависит от C, C зависит от E, а E недоступно».

источник

2015-11-26 b10y

, вероятно, нет. Если E не активен, то его иждивенцы не могут быть активированы. Это становится еще более ясным, когда я пытался вручную активировать компонент (скажем, B), но журналы сказали, что, поскольку E не разрешен, вы не можете активировать B. Итак, вам нужно сначала активировать E. – Abie

Этого не существует в настоящее время, хотя оно может быть разработано с использованием API ScrService. Это, безусловно, сделает интересный и полезный проект.

Ваши два диагностических варианта момент являются:

В scr:list и scr:info команды в Gogo оболочки. Они расскажут вам, почему отдельный компонент неактивен. Например, если вы спросите, почему A не активен, он скажет вам, что у него есть неудовлетворенная ссылка для службы B. Затем вам нужно будет проследить, какой компонент должен зарегистрировать услугу B и выяснить, почему это не активно. И так далее.
X-Ray plugin for Felix WebConsole предоставит вам графическое представление услуг и компонентов. Он не будет напрямую давать вам основную причину, как вы просили, но это может помочь опытному пользователю быстрее выявить проблему, чем команды scr.

источник

2015-11-26 11:46:20

Если вам нужен рабочий пример, в Apac Felix Dependency Manager мы внедрили команду оболочки, которая делает именно это. Он использует внутренний API для тяжелого подъема. Я не предлагаю вам прекратить DS, а скорее использовать этот код в качестве примера, когда вы делаете то, что предлагает Нейл (сами реализуйте такую логику). Для справки это команда «dm wtf» (аббревиатура, которую все мы знаем, означает «где ошибка»;)). –

Спасибо, Марсель. Основная проблема при построении такого рода диагностики заключается в том, что компоненты не зависят от компонентов. Компонент зависит от службы * *, которая может или не может быть предоставлена другим компонентом. Поэтому любое решение, которое вы построите, должно будет использовать определенное количество угадывания и эвристики. Он по-прежнему будет полезен, просто не идеален. –

Спасибо. BTW, если вы используете equinox (как я), соответствующими командами являются «список» и «comp». В этом файле реализованы команды: [SCRCommandProvider.java] (http://bit.ly/1MTuGJ6) – b10y

Недостающая зависимость OSGi диагностического компонента

ответ

Смежные вопросы