如何正确处理 ManagedServiceFactories 中的异常？答案

【问题标题】：How to properly handle exceptions in ManagedServiceFactories?如何正确处理 ManagedServiceFactories 中的异常？
【发布时间】：2016-12-30 14:32:03
【问题描述】：

OSGi ConfigurationAdmin 规范提到ManagedService 和ManagedServiceFactory 的实现可能会通过抛出ConfigurationException 来表示无效的传入配置。然而，除了这个声明之外，规范没有说明各种参与者应该如何处理这种情况，最重要的是，在这种异常之后应该是什么环境状态。

例如，假设ManagedServiceFactory 当前有一个具有一组有效属性的服务实例（比如说 service.pid=example.12345）；该服务实例由工厂发布到服务注册表中。然后，工厂被通知该服务实例的配置更新；但是，在验证时，更新方法确定传入的属性无效。因此，根据规范，工厂应该抛出一个ConfigurationException。

但是，如果什么都不做，环境仍然处于不稳定状态：现在注册表中有一个基于不再存在的配置的已发布服务；因此，每当ManagedServiceFactory 服务重新启动（例如，由于包更新或整个框架重新启动），将无法重新实例化该服务，它之前的有效配置已丢失。这打破了 Configuration Admin 子系统的持久性范式，并对某些 OSGi 环境的稳定性造成严重问题。

不幸的是，初始配置程序包没有简单的方法来检测其配置更改导致了 ConfigurationException，因此通常很难从该位置恢复稳定的配置。在我看来，在这种情况下，ConfigurationAdmin （持久地）恢复以前有效的配置会更合适，但不幸的是，规范中没有提到这种行为，我也看不到任何痕迹Felix 实现中的这种机制。

鉴于这些事实，似乎保持环境稳定性的唯一可能性是ManagedServiceFactory 实现首先取消注册并销毁它已收到无效配置属性的现有服务实例，并且只有在那之后，抛出强制的ConfigurationException。这将有效地导致与此时重新启动框架时相同的环境状态。同样，ManagedService 实现应该通过首先完全恢复其默认配置来处理无效配置，然后抛出 ConfigurationException。

那么，究竟应该如何处理ManagedService 和ManagedServiceFactories 配置更新中的错误呢？我的理解正确吗？从我在ManagedService 和ManagedServiceFactory 的示例/开源实现中看到的情况来看，大多数开发人员似乎完全忽略了这一方面。规范是否提供了有关该主题的任何说明？

【问题讨论】：

标签： java osgi

【解决方案1】：

一般的策略是将其记录为错误并祈祷它会尽快解决。配置异常的目的是向 devops 提供详细信息，以便快速纠正。

恕我直言，您所描述的策略是如此复杂和开放式，以至于它们往往会产生比他们所能解决的更多的问题。有人错误地创建了错误的配置，唯一的解决方案是修复该配置。我发现在处理这些特殊情况的一般系统中变得非常脆弱。一旦出现问题，您将处于无限空间中，而软件在推理您不知道的事物方面非常糟糕。

因此，除非您有一些非常具体的用例，否则我认为它不能也不应该有一个通用的解决方案。

【讨论】：

我不能同意“记录并祈祷它会得到解决”的策略。我的一些 OSGi 应用程序部署为安装在我们客户站点上的嵌入式机器。在这种情况下，“系统操作员”基本上是指一些仅具有基本技术知识的本地用户。期望他们在每次进行一些配置更新时正确调查日志以查找错误是一个太高的负担，最终的错误很可能不会被发现。让系统一开始似乎可以工作，但后来无法重新启动，当用户不再存在时，这是不可接受的......
至于我描述的策略，它们实际上非常简单且可预测。他们不会尝试修复无效配置，而只是通过恢复先前有效的配置或重置@987654321 来使系统脱离灰色区域（即，系统看起来工作正常但无法重新启动） @ 到与此时系统重新启动时相同的状态，从而使系统管理员可以立即看到配置问题。
我同意这个问题几乎没有万能的解决方案。无论如何，我在这里发布问题只是为了确保我没有错过一些关键点并让其他开发人员获得有关此问题的经验。感谢分享。不过，我会将问题重新发布到 osgi-dev 邮件列表：我认为将有关该主题的一些一般性建议正式化是可取的......

【解决方案2】：

一般来说有三种策略来处理这个问题：

拒绝无效配置但保持之前的状态
拒绝无效配置，像之前没有配置一样销毁当前状态
拒绝无效值，尽可能应用有效值

选择什么，您决定抛出异常、在日志中打印警告、发送电子邮件或弹出弹出窗口在很大程度上取决于您的系统和用例。

例如，如果您有一个 UI 并且用户可以更改配置，您可以简单地保存旧配置，如果您检测到错误，您可以要求用户更正或恢复配置。

更好的是，您可以使用MetaTypeService 描述配置要求，以便在应用之前验证配置。

如果你有一组配置文件，你最好先备份一下，这样你就可以恢复:)

【讨论】：