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

【问题标题】：What is the proper way of disabling an OSGi service at service start?在服务启动时禁用 OSGi 服务的正确方法是什么？
【发布时间】：2010-12-06 16:38:32
【问题描述】：

我创建了一个带有公开（声明性）服务的 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 Service Platform Service Compendium 的声明性服务部分中找不到正确的行为，但我可能遗漏了一些东西

【问题讨论】：

标签： java osgi declarative-services

【解决方案1】：

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

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

OSGi 4.2 cmpn spec 中的第 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");
    }
}

干杯，米尔科

【讨论】：

【解决方案2】：

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

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

但是，这可能会造成混淆。在 Felix DS 中，我实现了一个扩展，组件可以更改它们自己的服务属性，尽管这还没有被规范接受。使用此扩展，组件可以在激活或修改成功时添加诸如 active=true 之类的服务属性，并在修改失败或停用时将其删除。服务的客户端可以过滤此服务属性，例如（主动=真）。

【讨论】：