OSGi 诊断组件的缺失依赖答案

【问题标题】：OSGi Diagnose Component's Missing DependencyOSGi 诊断组件的缺失依赖
【发布时间】：2015-11-26 11:02:28
【问题描述】：

在开发过程中，我们倾向于分解我们的声明式服务组件，所以 OSGi 自然不会激活其他依赖组件。有没有办法诊断潜在的问题，即。 “为什么组件没有被激活？”

对于一个简单的依赖图：

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

当E 无法激活所有依赖组件时，C、D、B、A 也不会被激活。我需要一个控制台命令来询问“为什么A 没有被激活？”并且答案将包含答案，“A 取决于 B，B 取决于 C，C 取决于 E，而 E 不可用”。

【问题讨论】：

可能没有。如果 E 未激活，则无法激活其依赖项。这更清楚了，当我试图手动激活一个组件（比如 B）时，但是日志说因为 E 没有解析，你不能激活 B。所以，你需要先激活 E。

标签： osgi

【解决方案1】：

目前不存在，但可以使用ScrService API 进行开发。这肯定会成为一个有趣且有用的项目。

您的两个诊断选项是：

gogo shell 中的scr:list 和scr:info 命令。这些将告诉您为什么单个组件不活动。例如，如果您问为什么 A 不活动，它会告诉您它对 B 服务的引用不满意。然后，您必须追踪应该注册B 服务的组件，并找出它不活动的原因。以此类推。
X-Ray plugin for Felix WebConsole 将为您提供服务和组件的图形表示。它不会按照您的要求直接为您提供根本原因，但它可以帮助有经验的用户比scr 命令更快地追查问题。

【讨论】：

如果您需要一个工作示例，在 Apache Felix 依赖项管理器中，我们已经实现了一个 shell 命令来执行此操作。它使用内部 API 来完成繁重的工作。我不是建议您应该放弃 DS，而是建议您在按照 Neil 的建议（自己实现这样的逻辑）时使用该代码作为示例。作为参考，它是“dm wtf”命令（我们都知道的首字母缩写词代表“哪里失败”；）。
谢谢马塞尔。构建这种诊断的主要问题是组件不依赖于组件。一个组件依赖于一个service，它可能由另一个组件提供，也可能不由另一个组件提供。因此，您构建的任何解决方案都必须使用一定数量的猜测和启发式方法。它仍然有用，只是不够完美。
谢谢。顺便说一句，如果您使用的是Equinox（就像我一样），则相应的命令是“list”和“comp”。命令在这个文件中实现：SCRCommandProvider.java
我们已经解决了这个问题，因为我们不仅对组件进行建模，而且对依赖项（包括服务依赖项，还包括配置依赖项）进行建模。我们还知道如果组件已解析，它会公开哪些服务。当然，现在您可以制作高度动态的场景来打败我们的算法，但在大型项目的实践中，它对我们非常有效。
@MarcelOffermans 当然，您当然可以计算出 DS 组件应该提供的服务，只要它们使用简单的<provide> 元素。但任何人都可以通过编程方式或使用不同的组件模型等方式提供服务。