(guice メーリング リストに x-posted)
私は、既存のアプリケーションに組み込まれる新しいライブラリで Guice を試しています。現在、私たちのアプリはすべてSpringアプリであり、主に使用する傾向があるスレッドモデルに関係する、Springに関連付けられたいくつかの共通コードがあります. それは基本的に、論理スレッド (と見なされるもの) を提供します。
そのため、ジョブを投げることができ、特定のキーを持つジョブが、送信された順序で常に同じパイプに到達することが保証されます。通常、これはアプリケーションの存続期間中 1 つのスレッドですが、問題が発生した場合はワーカー スレッド (パイプをバックアップする) が破棄され、パイプが非アクティブ化され、新しいワーカーが作成され、そのワーカーでパイプが再アクティブ化されます。ここのすべての配線はスプリングによって提供されます。
私の新しいライブラリはこれをスレッドモデルに使用する必要があり、ロジックとドメイン側、つまりパイプラインで進行する作業とそれが表すロジックを構築するために Guice を使用する予定です。これは、「パイプ」(論理スレッドとも呼ばれる) スコープで特定のものを注入したいという、非常に危険に思える 1 つのことを除いて、私には非常に簡単に思えます。カスタム スコープ (および SimpleScope の実装) の wiki ページを読みましたが、いくつかの点が明確ではなく、明確化していただければ幸いです...
- パイプはJVMの存続期間中存続するため、スコープに入る必要があるようですが、決して終了しないようです。これの欠点はありますか?
- Spring マネージド Bean でスコープ エントリをトリガーするには、どのようなオプションがありますか? 春のコンテキストを作成し、SpringIntegration を使用して春の Bean を guice コンテキストに吸い込むだけの場合ですか?
- これは本当に不安定に聞こえますか?代わりに、パイプ ID をキーとするシングルトンでラップする必要がありますか?
乾杯マット