OSGi ConfigurationAdmin规范提到ManagedService和ManagedServiceFactory的实现可能会通过抛出ConfigurationException来表示无效的传入配置。然而，除了这一陈述之外，该规范没有说明各方应如何处理这种情况，最重要的是，在这种例外之后应该是什么样的环境状态。
例如，假设ManagedServiceFactory当前具有一组具有有效属性的服务实例（假设为service.pid = example.12345）;该服务实例由工厂发布到服务注册表中。然后，工厂被告知该服务实例的配置更新;但是，在验证时，更新方法确定传入属性无效。因此，根据规范，工厂应抛出ConfigurationException。
但是，如果没有其他方法，环境仍处于不稳定状态：现在注册表中已发布的服务基于不再存在的配置;因此，每当ManagedServiceFactory服务重新启动时（例如由于捆绑更新或整个框架重新启动），就无法重新实例化该服务，其以前的有效配置已丢失。这打破了配置管理子系统的持久性范例，并对某些OSGi环境的稳定性造成严重问题。
不幸的是，初始配置程序包没有简单的方法来检测其配置更改是否导致ConfigurationException，这使得通常无法从该位置恢复稳定的配置。在我看来，在这种情况下，ConfigurationAdmin（持久地）恢复以前有效的配置会更合适，但遗憾的是在规范中没有提到这种行为，我没有看到任何痕迹菲利克斯的实施中的这种机制。
鉴于这些事实，似乎维持环境稳定性的唯一可能性是ManagedServiceFactory实现首先取消注册并销毁已收到无效配置属性的现有服务实例，并且仅在之后那，抛出强制ConfigurationException。这将有效地产生与在该点重新启动框架时相同的环境状态。同样，ManagedService实现应首先完全恢复其默认配置，然后抛出ConfigurationException来处理无效配置。
那么，ManagedService和ManagedServiceFactories配置更新中的错误究竟应该如何处理？我的理解是否正确？从我在ManagedService和ManagedServiceFactory的示例/开源实现中看到的，大多数开发人员似乎完全忽略了这个方面。该规范是否对该主题做出了任何澄清？
答案 0 :(得分：0)
一般策略是将其记录为错误并祈祷它很快就会得到解决。配置异常的目的是向devops提供详细信息，以便快速纠正。
你所描述的策略是无可救药的复杂和开放的结果，他们倾向于创造更多的问题然后他们可以解决。有人在创建错误配置时犯了一个错误，唯一的解决方案是修复该配置。我发现在处理这些特殊情况的一般系统中变得非常脆弱。一旦出现问题，你就处在一个无限的空间里，软件在推理你不了解的事情时非常糟糕。
因此，除非您有一些非常具体的用例，否则我认为它不能，也不应该有一般解决方案。
答案 1 :(得分：0)
一般来说，有三种策略可以解决这个问题：
选择什么，你决定抛出异常，在日志上打印警告，发送电子邮件或弹出一个弹出窗口取决于你的系统和用例。
例如，如果你有一个用户界面并且用户可以更改配置，你可以直接保存旧配置，如果你发现错误，你可以要求用户更正或恢复配置。
更好的是，您可以使用MetaTypeService来描述配置要求，以便在应用之前验证配置。
如果您有一组配置文件，最好先备份，然后才能恢复：）