0

私は現在、構築されたインスタンスを破棄するのを忘れているため、iPojo リークで多くの問題を抱えています。これは、ipojo Factory 手法を使用した命令型インスタンス化の避けられない欠点だと思います。基本的に、サービスが必要なときは を呼び出すことfactory.createComponentInstance(config)で言います。これにより、2 つの参照を保持する必要があります。1 つは消費したいサービス用ですが、もう 1 つは iPojoComponentInstance用であり、コンシューマーが完了したときに を呼び出すことができますcomponentInstance.dispose()。そうじゃないなら漏れてる

消費者が iPojo サービスとそのインスタンスのライフサイクルを処理する必要がない場合に、これを行うためのより宣言的な方法はありますか?

私のユースケースを単純化するために、ボタンを含む UI があり、ボタンが押されるたびに、iPojo サービスの新しい一意のインスタンスが必要であると想像してください。理想的には、インスタンスがスコープ外になると、コンシューマーが何もしなくてもインスタンスが GC されます。

サービスをインスタンスとして使用するのが私の間違いかもしれませんが、通常のクラスの代わりにサービスを使用して を呼び出す理由が 3 つありますnew。

  1. サービス実装は代用可能でなければなりません
  2. 消費者は、実装/プロバイダーではなく、インターフェースに依存する必要があります。これは、＃1だけでなく、具体的な実装に依存するときに引き出される推移的な依存関係が多数あるためです。
  3. サービス impl 自体には、iPojo によって注入されることを望んでいる依存関係がいくつかあります (依存性注入)。

2 番目のリクエストとして、iPojo の適切な使用例として使用できる、iPojo を使用したオープンソースの実際の (つまり、ダミーではなく、デモの) プロジェクトを知っている人はいますか?

4

1 に答える 1

1

コンポーネント インスタンスを作成する代わりに、おそらくカスタムの「作成戦略」を使用する必要があります。したがって、コンポーネント インスタンスは 1 つだけですが、複数の「実装」インスタンス (サービス オブジェクト) が管理されます。これらのオブジェクトをいつ作成して破棄するかを決定します。http://felix.apache.org/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/providing-osgi-services.html#service-serving-object-creationに関する詳細情報.

iPOJO を使用するプロジェクトについては、iPOJO に依存する Wisdom Framework を参照してください: http://wisdom-framework.org (そこで利用可能なコード: github.com/wisdom-framework/wisdom/)

于 2015-04-21T06:59:38.920 に答える