OSGiのは、アンインストール作業を備えていますが、バンドルがまだ

Question

EDITを設置しています。 OSGiは「状態変化が進行中...」と応答しますが、他の要求を受け入れることで問題が発生します。

不思議なことに、機能のアンインストールは成功しますが、バンドルのアンインストールは失敗します。私たちは、アンインストール要求を適切に発注し、ステップ間に遅延を追加することでこれに対処していますが、より堅牢なソリューションが望まれます。

提案したように、私はまた、ステップの間に "osgi：refresh"を追加しようとしました...同じ動作です。後続のリクエストなどを遅らせるために「リフレッシュパッケージ」がまだ実行中であることを検出する別の方法はありますか？

ここ

は詳細...

karaf @ルート>機能は次のとおりです。PolicyUtil
karafの@ルート>機能をアンインストール：POLICY1
karaf @ルート>機能をアンインストールのための：進行中のPolicy2の
状態変化をアンインストールしますスレッド "Refresh Packages"による "file：/policy2.jar"のバンドル
karaf @ root> features：uninstall Policy3
バンドル "file：/policy3.jar"の状態が "Refresh Packages"スレッドによって変更されています。
karaf @ルート>機能：Policy4
karaf @ルート>機能をアンインストール：スレッド "更新パッケージ" による：バンドル "/enabler1.jarファイル" のために進行中のEnabler1
状態変化をアンインストールします。
karaf @ root> features：uninstall Enabler2
バンドル "file：/enabler2.jar"の状態が "Refresh Packages"スレッドによって変更されています。リスト

[277] [インストール] [] [] [60]：

その後

...（間違った）

のOSGiを我々はアンインストール機能（正しい）で終わるが、一部のバンドルがまだインストールpolicy2の
[278] [インストール] [] [] [60] policy3の
[280] [インストール] [] [] [60] Enabler1
[281] [インストール] [] [] [60] Enabler2

機能：リスト

[アンインストール] [1.0] PolicyUtilレポ0
[アンインストール] [1.0]ポリシー1レポ0
[アンインストール] [1.0] Policy2のレポ0
[アンインストール] [1.0] policy3のレポ - 0
[アンインストール] [1.0] Enabler1レポ-0
[アンインストール] [1.0] Enabler2レポ-0

Answer 1

申し訳ありませんが、私はこれを掘り下げており、問題とオプションを理解していると思います...回答に感謝します。

"features：uninstall [name]"が実行されると、機能の各バンドルに対してbundle.uninstall（）、次にrefreshPackages（）が呼び出されます。その後、すべてのバンドルがアンインストールされた後、すべてのバンドルに対してrefreshPackages（）が呼び出されます。問題は、refreshPackages（）が非同期（OSGi spec）で、バンドルが解決状態になっていることです。解決機能/バンドルをアンインストールする後続の要求は、期待通りに完了できません。

アンインストールの間に十分な遅延がある場合、または後でアンインストールが実行された場合（refreshPackages（）が完了した後）...すべて正常に動作します。 （制御が困難）、アンインストール時の順序に依存する機能/バンドル

は、アンインストールのコマンド間の遅延を入れ

オプション...

1. （正確ではありません）
2. 期待される機能/バンドルを確認するにはアンインストールされています
3. FrameworkEvent.PACKAGES_REFRESHEDイベントを受け取ります（イベントはコンテナワイドであるため、複雑で保証されていません。this exampleを参照）
4. ...同期さわやかなパッケージオプション（Karaf 2.1.3用this issue/resolutionを参照）

Answer 2

私の経験では、バンドルのリソースが別のバンドルによって参照または使用されている場合に発生します。この場合、フレームワークはバンドルを削除できず、jarファイル全体がVMによって処理されます。

すべての参照が削除されていることを確認してください。一般的な間違いは、バンドル内でインスタンス化されたオブジェクトの1つでもスレッドを実行しています。これは、削除できない使用中広告のリソースとしてもカウントされます。

Answer 3

どのような例外が発生するかわかりませんが、1つのことに注意してください。osgi:uninstallのようなシェルコマンドを使用してバンドルをアンインストールすると、効果的にBundle.uninstall()が呼び出されます。 Javadocで読むことができるように、これはすべての話ではありません。

フレームワークはフレームワークの残りの部分に最小限の影響を与える操作を優先するため、をアンインストールすると、はすべての関連パッケージを削除することなくアンインストールできます。本当にすべてを削除したい場合は、osgi:refreshコマンドを使用してください。詳細については、Felix FAQを参照してください。

私が与えることができる最良のアドバイスは、互いに交差する可能性のある複数の要求を発行しないことです。バンドルのセットを削除したい場合は、非クロスオーバーのuninstall()リクエストと、その後に続くrefreshPackages()リクエストを実行します。また、私は、「通常の」コンソールとKarafを使ったバンドル管理を1つのシステムで混在させません。

バンドルのインストールと削除に外部マネージャを使用することも考えられます。リモート管理が必要な場合は、Apache ACE（公開：私はApache ACEコミッタです）に行くことができます。

Answer 4

OORをサポートするために、Karaf /フェリックスを修正することができます簡単なアンインストールこのコマンドを使用して、アプリ：

karafの2.2.xの：

は、OSGi：--force yourapp-機能/ 0.0.1.SNAPSHOTをアンインストール

Answer 5

私の場合は、機能をアンインストールし、吊りバンドル番号と、その後シャットダウンkaraf（3.xは）気づきました。次に、フォルダ[karaf-install]/data/cache/[hanging-bundle-number]のサブフォルダを削除しました。 今度はkarafを再起動し、バンドルウォーズはbundle：リストに表示されません。