ManagedServiceFactoriesで例外を適切に処理する方法は？

Question

OSGi ConfigurationAdmin仕様では、ManagedServiceとManagedServiceFactoryの実装では、ConfigurationExceptionを投げて無効な着信構成を通知する可能性があると記載されています。しかし、この声明とは別に、このスペックは、さまざまなアクターがどのように状況を処理すべきか、そして最も重要なのは、そのような例外の後に環境の状態がどうなるべきかについては言及していません。

たとえば、ManagedServiceFactoryは現在、有効なプロパティーセットを持つサービスインスタンス（service.pid = example.12345）を持っているとします。そのサービスインスタンスは工場によってサービスレジストリに公開されます。次に、そのサービスインスタンスの構成更新が工場に通知されます。ただし、検証時に、更新メソッドは受信プロパティが無効であると判断します。その仕様に基づいて、工場はConfigurationExceptionを投げるべきです。

しかし、それ以外のことが行われなければ、環境は不安定な状態のままです。レジストリには、もはや存在しない設定に基づいて公開されたサービスがあります。その結果、ManagedServiceFactoryサービスが再起動されるたびに（たとえば、バンドルの更新やフレームワークの再起動が原因で）、以前の有効な構成が失われたそのサービスを再インスタンス化することはできません。これにより、Configuration Adminサブシステムの永続パラダイムが破られ、一部のOSGi環境の安定性に関する重大な問題が発生します。

残念なことに、最初のコンフィグレータバンドルがコンフィグレーションの変更によってコンフィグレーションが変更されたことを検出するのは簡単ではなく、一般的にはその場所から安定したコンフィグレーションを復元することはほとんど不可能です。このような状況では、ConfigurationAdminが以前の有効な構成を（永続的に）復元することがより適切になると思われますが、残念なことにそのような動作は仕様には言及されていません。フェリックスの実装におけるそのようなメカニズム。

環境の安定性を維持する唯一の可能性は、ManagedServiceFactory実装が最初に無効な構成プロパティを受け取った既存のサービスインスタンスを登録解除して破棄し、委任されたConfigurationException。これにより、その時点でフレームワークが再起動された場合と同じ環境状態になります。同様に、ManagedServiceの実装では、最初に完全にデフォルト設定を復元して無効な設定を処理し、ConfigurationExceptionを投げる必要があります。

したがって、ManagedServiceとManagedServiceFactories構成のアップデートのエラーをどのくらい正確に処理する必要がありますか？私の理解は正しいのですか？例/オープンソースの実装であるManagedServiceとManagedServiceFactoryの中からわかるように、この側面はほとんどの開発者によって全く無視されているようです。スペックは対象に関する説明を提供していますか？

Answer 1

一般的な戦略は、エラーとしてログに記録し、すぐに解決するよう祈ることです。構成例外の目的は、devopに詳細な情報を提供して迅速に修正できるようにすることです。

あなたが説明している戦略は非常に複雑でオープンに終わっているため、解決できない問題が増えています。誰かが間違った構成を作成するのに間違いを犯しましたが、唯一の解決策はその構成を修正することです。私は、これらの例外的なケースを非常に脆弱に扱う一般的なシステムではそうしたことがわかります。いったん何かが間違ってしまうと、あなたは無限の空間に入り、ソフトウェアはあなたが知らない事について推論するのが非常に悪いです。

非常に特殊なユースケースがある場合を除き、一般的な解決方法があるとは思われません。