Guice を JSF 1.2 (Sun RI) アプリケーションに統合しようとしています。マネージド Bean に対して次のことを実行できるようにしたいと考えています。

2. Guice@Injectアノテーションを使用して依存関係を注入してから、
3. @PostConstructアノテーションを使用して初期化を実行する

私の問題は、アノテーションが処理さ@PostConstructれる前にメソッドが常に呼び出されることです。@Injectこの問題の解決策を知っている人はいますか?

管理対象 Bean:

マネージド Bean 宣言:

Guice バインディング:

私は次のことを試しました：

• 手動で呼び出すInjector.injectMembers(Object)(@PostConstructスーパークラスでは処理されません)
• カスタムを使用するVariableResolver(前に@PostConstruct処理されます) @Inject
• MyFaces の使用GuiceResolver(まったく機能していないように見えた - おそらくこの問題に関係している)

これが物事へのアプローチの間違った方法であると思われる場合は、他のオプションを検討させていただきます...どんな助けにも感謝します。

編集

Guice 1.0 を使用していました。Guice 2.0 にアップグレードしましたが、問題は残っています。私の問題に関連していると思われる議論をいくつか見つけました...しかし、この情報の使い方がわかりません:(

私が理解している限りでは、 Google Guice 2.0 がリリースされたのはそれほど前のことではありません。しかし、中央リポジトリにはまだ古いバージョンの1.0があることがわかりました。Google Guice 2.0 で maven2 リポジトリを見つけることができる場所を教えてください。

アプリ + ビルド システムを使って大規模にこれを試したいと思っていますが、優先順位が高いため後回しにされています。これは、Guice モジュールをロードするための優れた方法のように思われ、「ハードコードされた構成」に関するよくある不満を回避します。個々の構成プロパティが独自に変更されることはめったにありませんが、ほとんどの場合、通常はさまざまな環境 (デバッグ、運用など) 用の一連のプロファイルがあります。

ServiceLoader を使用すると、特定のタイプのサービスとして定義されたすべての実装のリストを取得できます。これを Guice と組み合わせると、次のようになります。

使用例 (guice-servlet プロジェクトの動的サーブレットローダーとして):

サービス (モジュールとしてパッケージ化) は、個別の jar ファイルにパッケージ化されます。それぞれの中で、メタデータでクラスを定義します。

Maven を使用しているため、プロファイルの依存関係を介して実行時にさまざまな実装を取り込むことができるため、これが理想的であると考えています。このように Guice を使用している人はいますか?

そうでない場合は、この例を自由に使用して、どのように機能するかを確認してください。(ServiceLoader は JDK6+ でのみサポートされます)

私は Guice を初めて使用し、大量のレガシー コードを含むアプリケーションで Guice を使用しています。次のようないくつかのクラスがあります。

Guice を使用して変更されないインスタンスをバインドする方法は明らかですが、変更されるインスタンス (つまりトランザクション) はどうなるでしょうか? Guice を使用して、Transaction が変更されたときに別のインスタンスを挿入する方法はありますか? Transaction インスタンスは、十分にサポートされている JPA/Hibernate/Spring トランザクションの 1 つではないことに注意してください。

私が考えることができる最も侵襲性の低いアプローチ (トランザクションを使用するすべてのクラスを一度に移行する必要を回避する) は、Guice を使用して、オブジェクトをインスタンス化するときにのみ Transaction を注入し、必要に応じてトランザクションを更新する既存のアプリケーション コードを保持します。 . たとえば、このプロバイダを使用して、トランザクションの現在のインスタンスで新しいオブジェクトを挿入できます。

アプリケーション ロジックは次のようになります。

各クラスを一度に移行することなく、既存のクラスが使用する Transaction のインスタンスを更新する他の方法はありますか?

私は、数百の数の Bean を持つ Spring アプリケーションに取り組んでおり、使用と文書化が非常に面倒になっています。

保守性、ドキュメンテーション、および一般的な使用法に役立つ多数の Bean を使用した DI 対応アプリの経験に興味があります。

このアプリケーションは Spring ベースで、いくつかのコンテキスト ファイルがありますが、DI コンテナーや DI 全般に関する提案については、喜んで耳を傾けます。

newたぶん私は盲目ですが、Guiceを使用して（それから始めて）このメソッドの呼び出しを置き換える方法がわかりません：

newテストのために、プロセッサの異なる実装があるかもしれないので、私は呼び出しを避け、その過程で実装への依存を取り除きたいと思います。

私のクラスがProcessorのインスタンスを覚えていれば、コンストラクターを介してそれを注入できますが、Processorsは不変であるように設計されているため、毎回新しいものが必要です。

Guice（2.0）でそれを達成するにはどうすればよいですか？

aopallianceの aop を使用して、依存性注入に Guice を使用しています。aopalliance とは何か、sourceforge ページにあるバージョン (2004 年以降) を誰が実装したのか、私にはよくわかりません。AspectJ などのよく知られているパッケージではなく、このバージョンを guice が使用しているのはなぜですか?

また、aopalliance バージョンに関するチュートリアルをご存知ですか?

ありがとう

Google Guice for Dependency Injectionをいじって、既存のアプリケーションに統合し始めました。ここまでは順調ですね。依存関係に加えて、文字列、データソースなどを必要とする多くのクラスがあります。NamedBindingsがあることは知っていますが、クラスごとにコンストラクターに渡さなければならない単純な文字列ごとにアノテーションを作成したくはありません。次に、AssistedInjectと呼ばれるものがあり、ファクトリの実装を作成してくれます。うわー、しかし私はまだ工場のインターフェースを定義する必要があります。依存関係があるクラスでは問題ありませんが、このサンプルクラスについてはどうでしょうか。

Guiceの使い方、より一般的にはDIの正しい使い方がわからない場合があります。「よく耳にしますが、XYZフレームワークは新しいものです。」しかし、これは暗黙のうちに、DIフレームワークを使用してすべてのインスタンスを作成する必要があることを意味します。

必要なインスタンスは1つだけです

このクラスのインスタンスが1つだけ必要な場合はどうなりますか？このクラスには、2つの文字列以外に依存関係はまったくありません。一度だけインスタンス化され、シャットダウンフックとしてJVMに渡されるシャットダウンフックについて考えてみてください。Guiceでこのインスタンスを作成する必要がありますか？注入するものがないため、これは非常に馬鹿げているように見えますが、Guideの両方のパラメーターを渡すためのファクトリインターフェイスを作成し、FooBarClassがDIを使用するためのインターフェイスを作成する必要があります。

複数のインスタンスが必要です

このクラスの複数のインスタンスが必要な場合にも同じことが当てはまります。依存関係はありませんが、何も得られないようにボイラープレートコードをたくさん作成する必要があります。これは私には間違っているようです。

では、DIやGuiceをどのように使用することになっていますか？

どうもありがとう！

次のように、@Injectプロパティと@SingletonプロパティでGoogleGuiceを使用しようとしています。

私は持っています：

1. configure()空のメソッドを持つモジュール。
2. インターフェイスIFoo
3. @Singletonで注釈が付けられたクラスFoo（IFooを実装）、@Injectで注釈が付けられたパラメーターのないコンストラクター。これは、単一の注釈付きコンストラクターです。

クラス、コンストラクター、およびインターフェースはパブリックですが、それでも次のエラーが発生します。

IFooの実装はバインドされていません。

(guice メーリング リストに x-posted)

私は、既存のアプリケーションに組み込まれる新しいライブラリで Guice を試しています。現在、私たちのアプリはすべてSpringアプリであり、主に使用する傾向があるスレッドモデルに関係する、Springに関連付けられたいくつかの共通コードがあります. それは基本的に、論理スレッド (と見なされるもの) を提供します。

そのため、ジョブを投げることができ、特定のキーを持つジョブが、送信された順序で常に同じパイプに到達することが保証されます。通常、これはアプリケーションの存続期間中 1 つのスレッドですが、問題が発生した場合はワーカー スレッド (パイプをバックアップする) が破棄され、パイプが非アクティブ化され、新しいワーカーが作成され、そのワーカーでパイプが再アクティブ化されます。ここのすべての配線はスプリングによって提供されます。

私の新しいライブラリはこれをスレッドモデルに使用する必要があり、ロジックとドメイン側、つまりパイプラインで進行する作業とそれが表すロジックを構築するために Guice を使用する予定です。これは、「パイプ」(論理スレッドとも呼ばれる) スコープで特定のものを注入したいという、非常に危険に思える 1 つのことを除いて、私には非常に簡単に思えます。カスタム スコープ (および SimpleScope の実装) の wiki ページを読みましたが、いくつかの点が明確ではなく、明確化していただければ幸いです...

1. パイプはJVMの存続期間中存続するため、スコープに入る必要があるようですが、決して終了しないようです。これの欠点はありますか?
2. Spring マネージド Bean でスコープ エントリをトリガーするには、どのようなオプションがありますか? 春のコンテキストを作成し、SpringIntegration を使用して春の Bean を guice コンテキストに吸い込むだけの場合ですか?
3. これは本当に不安定に聞こえますか?代わりに、パイプ ID をキーとするシングルトンでラップする必要がありますか?

乾杯マット