5

osgi の仕組みを学ぼうとしています。バンドル アクティベーター クラスの start-method が実行されたときにコンソール出力を表示する最初の hello-world バンドルを作成しました。ここで、遅延開始メカニズムについて読み、このフラグをバンドル マニフェストに追加しました。次に、equinox コンソールを起動し、バンドルをインストールして起動しました。しかし今、バンドルが「開始中」としてマークされることを期待していたでしょう。代わりに、すでに start メソッドを呼び出しており、アクティブとしてマークされています。怠惰な開始メカニズムに何か問題があることを理解しましたか???

4

2 に答える 2

8

バンドル内のバンドルとクラスに依存する他のバンドルがある場合、遅延開始フラグが使用されます。

2 つのバンドル A と B があるとします。

  • A はクラス C をエクスポートします
  • B は A に依存する
  • B には、C を参照するクラス D が含まれています

バンドル B がアクティブになるとどうなりますか?

lazy-load フラグがない場合、最初に A バンドルが読み込まれ、アクティブ化されます。

lazy-load フラグを使用すると、クラス D がクラス C を参照する必要があるまで、A バンドルはロードまたはアクティブ化されません。

これにより、アクティベーション プロファイルに大きな違いが生じる可能性があります。バンドルのロードとアクティベーションは、遅延ロード フラグを使用して可能な限り遅く発生するように延期されるため、バンドルからの初期応答が非常に高速になるためです...

それどころか、このフラグは、B のメソッドの実行時間について推論することをはるかに困難にします。これは、いつでもバンドルのロードとアクティブ化で傍受できるためです....

于 2011-07-16T08:44:38.353 に答える
3

インストール後に既にバンドルを開始しているとのことでした。バンドルを手動で開始すると、遅延アクティブ化ポリシーに関係なくアクティブ化されます。

OSGi 仕様によると、アクティベーションには次のことが当てはまります。

レイジー アクティベーション ポリシーは、バンドルが開始されると、バンドルからクラスがロードされるまでアクティベートしてはならないことを示します。通常のクラスのロード中、またはバンドルの loadClass メソッドを介して。リソースの読み込みはアクティベーションをトリガーしません。デフォルトの熱心なアクティブ化ポリシーからのこの変更は、バンドルとそのイベントの状態に反映されます。レイジー アクティベーション ポリシーを使用してバンドルを開始する場合は、次の手順を実行する必要があります。

  • バンドルのバンドル コンテキストが作成されます。
  • バンドル状態は STARTING 状態に移行します。
  • LAZY_ACTIVATION イベントが発生します。
  • システムは、バンドルからのクラス ロードが発生するのを待ちます。
  • 通常の STARTING イベントが発生します。
  • バンドルがアクティブ化されます。
  • バンドルの状態は ACTIVE に移行します。
  • STARTED イベントが発生します。

Bundle Activator の start メソッドが例外をスローしたためにアクティベーションが失敗した場合は、Bundle Activator の stop メソッドを呼び出さずにバンドルを停止する必要があります。これらの手順は、図 4.29 のフローチャートに示されています。このフローチャートは、通常の熱心なアクティベーションとレイジーなアクティベーションのアクティベーション ポリシーの違いも示しています。

更新: 回答を書いた時点でどのバージョンの仕様を開いたかはわかりません (ただし、4.2 または 4.3 のいずれかだったと思います)。現在の v5.0 仕様とセクション 4.4 を確認しました。 6.2 には、実際の、意味的に同等の場所が含まれています。

于 2011-07-16T08:44:09.387 に答える