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的示例/开源实现中看到的这一点，大多数开发人员似乎完全忽略了这一方面。规范中是否对此主题有任何澄清？
最佳答案
一般策略是将其记录为错误，并祈祷将尽快解决。配置异常的目的是向设备提供详细信息，以便可以快速对其进行更正。
您所描述的策略令人难以置信，其复杂性和开放性令人望而却步，以至于它们往往会制造出更多无法解决的问题。有人错误地创建了错误的配置，唯一的解决方案是修复该配置。我发现，处理这些特殊情况的一般系统变得非常脆弱。一旦出现问题，您将处于一个无限的空间，并且软件在推理您不知道的事情时非常糟糕。
因此，除非您有一些非常具体的用例，否则我认为它不可能也不会有通用的解决方案。