在服务启动时禁用 OSGi 服务的正确方法是什么？

Question

我创建了一个带有公开（声明性）服务的 OSGi 包。如果我在调用 activate 时发现有些问题导致我无法提供服务，我需要防止它被暴露。目前激活函数看起来像这样：

public void activate(ComponentContext context, Map<String, Object> properties) {
    pid = (String) properties.get(Constants.SERVICE_PID);
    try {
       ...
    }
    catch(Exception e) {
        context.disableComponent(pid);
    }
}

另一种选择是只包装/传播异常（或抛出一个新的异常，具体取决于），如下所示：

public void activate(ComponentContext context, Map<String, Object> properties) {
    try {
       ...
    }
    catch(Exception e) {
        throw new ComponentException("Some reason");
    }
}

我找不到 OSGi 服务平台服务纲要，但我可能会遗漏一些东西

Answer 1

嗯，对我来说，如果发生错误，应该抛出异常似乎是合乎逻辑的。基本上，您所做的就是在 start 方法中模仿 BundleActivator 的行为。当 start 方法返回且没有出现异常时，bundle 就进入 ACTIVE 状态（否则它仍处于 RESOLVED 状态）。我在 DS 规范中找到了一段有点合适的段落（我突出显示了有趣的部分）：

组件实例必须先完成激活，然后才能停用。一旦组件配置被停用或由于异常而无法激活，SCR 必须取消绑定所有组件的绑定服务，并丢弃对与激活关联的组件实例的所有引用。

OSGi 4.2 cmpn 规范中的第 112.5.6 P.320 节

我同意这不是很清楚，所以如果你想安全起见（安全总比后悔好），我建议进行组合（规范允许）。

public void activate(ComponentContext context, Map<String, Object> properties) {
    try {
       ...
    } catch(Exception e) {
        context.disableComponent((String) properties.get(Constants.SERVICE_PID));
        // not sure if a CE is best here... Maybe just rethrow the original one
        throw new ComponentException("Some reason");
    }
}

干杯，
米尔科

Answer 2

禁用自身的组件不太可能是合适的 OSGI 设计。当情况改善时，什么会启用该组件？启用/禁用状态旨在成为与激活/停用不同的逻辑级别。

正确设计的 OSGI 代码应该正确处理激活失败时抛出 ComponentException（或其他异常）的代码。假设组件注册了一个服务，服务引用将可用，但尝试获取该服务将返回 null。 DS 将正确处理对服务的引用，任何直接尝试从服务引用获取服务的代码都必须正确处理服务实际上不可用的可能性。

然而，这可能会令人困惑。在 Felix DS 中，我实现了一个扩展，组件可以通过该扩展更改自己的服务属性，尽管这尚未被规范接受。使用此扩展，组件可以在激活或修改成功时添加服务属性，例如 active=true，并在修改失败或停用时删除它。服务的客户端可以过滤该服务属性，例如(active=true)。