問題タブ [jsr330]

http://www.mkyong.com/jsf2/jsf-2-0-spring-integration-example/のガイドラインに従ってSpring + JSFアプリケーションを実装していますが、最新のSpringバージョン（つまり、3.x、それドキュメントによると、すでに JSR 330 実装が含まれているため、これは問題にならないはずです) と私自身のクラスです。これが、前述の例との違いです。

これはNullPointerException、Bean (JSF 管理として機能する) Bean が Spring Bean のインスタンスの注入を受けていないことを示しています。@Namedすべての Bean は適切な場所 ( 、 )で JSR 330 アノテーションを使用し、@InjectBean のインターフェースと変数 (@Injectアノテーションの下) は通常の命名パターンに従います...

だから - この状況をデバッグする方法。たとえば、Spring アプリケーション コンテキストに含まれるすべての Bean を確認する方法はあります。たとえば、Spring コンテキストが適切に初期化されていないことを判断できます。アプリで何が起こっているかを確認する方法が他にあるかもしれません（デバッグインジェクション）？

次のようなコードが見つかりました

(JSR-330 アノテーションを利用して) "s" の文字列値を渡すのに非常に便利です。どのコンテナを使用するかについては、可能な限り柔軟に対応したいと考えています。そのため、Picocontainer も同様です。

書かれているように、Picocontainer は inject を黙って無視します。PicoContainer に「文字列が注入されました!」などの注入を指示するにはどうすればよいでしょうか。ここ？

この質問に関係のない他のライブラリの中でも、Java 6、Spring Framework 3.1.2、Mule-ESB3.3.0で構築されたエンタープライズアプリケーションがあります。

私たちのBeanとサービスはすべて、自動コンポーネントスキャンと依存性注入（EJBなし、サービスBeanのみ）のために、それぞれJSR-330アノテーションで宣言さ@Namedれています。@InjectJBoss 4.2.3（テスト環境）にデプロイすると、すべてが正常に機能します。ただし、WebSphere 7にデプロイすると、JSR-330アノテーションが機能していないように見えます。でマークされたBeanは@Namedまったく検出されません。

すべてが正しく設定されていることを確認できます（JBossで動作しているため）。具体的に<context:component-scan />は、base-package属性が正しく定義され、scope-resolver使用するように属性が正しく構成されていますJsr330ScopeMetadataResolver（これも使用せずに試しました）。

WebSphere 7（7.0.0.23）がそのような種類の注釈をサポートしていない可能性があることを認識しています。私はまだSpringの同等物@Componentでそれをテストしていません。@Autowired残念ながら、Spring Frameworkを内部で使用している場合でも、クラスがSpringに直接依存しないように、JSR330アノテーションを使用したいと考えています。

それでも、WebSphere7がJSR330アノテーションをサポートしていないという明確なステートメントを探すために、丸1日を費やしましたが、これまでのところ何も見つかりませんでした。

<context:component-scan />さらに、ファイル内のディレクティブを介して、Spring Frameworkがすべての作業を実行していると想定しているため、なぜ機能しないのかわかりませんapplication-context.xml。

誰かがこの問題に光を当てることができますか？

WebSphere 7でアノテーションを介して依存性注入をアクティブ化する方法はありますか？

JSR 330 @Named/@InjectアノテーションからSpring独自のアノテーションに戻す@Componentと@Autowired、機能する可能性がありますか？

必死の試みで、Springを拡張ComponentScanBeanDefinitionParserして、WebSphere7でもJSR330アノテーションを検出できるようにすることはできますか？

何も機能しない場合は、最終的にプレーンXML構成にフォールバックします。ただし、XMLで手動で構成するBeanが数百あるため、これは非常に望ましくありません。

2 つの Maven プロジェクト、Web アプリ、および「サービス」プロジェクトがあります。私はすべてを一緒に配線するためにスプリングを使用しています。application-context.xml でマップを作成し、それをクラスに挿入したいと考えています。Web アプリケーションを起動しようとすると、エラー メッセージが表示されます。

これが私のクラスです：

および application-context.xml:

次のエラーが表示されます。

これは、アプリケーションコンテキストで文字列を定義し、コンストラクターがそれをクラスに挿入するときに機能します。マップに対して同じことを行うにはどうすればよいですか?

質問が明確でない場合は、私の言葉を許してください。JSR 330 アノテーションを使用したい。そして、DIプロバイダーを切り替えることができるようにしたい. 現在、私のアプリケーションは、ある時点で spring または google-guice を使用する必要があることを知る必要があります。これを回避する方法はありますか？

今私は電話しなければなりません：

アプリのコンテキストを取得して Bean を取得します。私の理解では、google-guice の場合、google-guice 固有のコードを使用する必要があります。

私の理解は正しいですか、それとも完全に何かを逃しました。

これは以前に何百回も尋ねられたと確信していますが、質問が見つからないようですので、他のスタックオーバーフローの回答を参照してください。

ほとんどの Spring ユーザーは、注入が必要な非シングルトン Bean であるオブジェクトに対して何をしますか? たとえば、毎回新しいインスタンスを作成したい Customer のようなクラスがあります。それがエンティティであり、 @PreRemove または他の場所で反復するリスナーを注入したいとしましょう。通常の解決策は @Configurable を使用することですが、それはほとんど回避策のようであり、これらを処理するためのより標準的な方法があるかどうか疑問に思いました。

私が考えることができる唯一のことは、マネージ Bean である CustomerRepository クラスにファクトリ newCustomer インスタンス メソッドを作成することです。次に、リスナーを Customer (最も自然な場所) に注入する代わりに、CustomerRepository に注入し、Customer ala new Customer( inspectedListeners ) への明示的なコンストラクター引数として指定します。

人々は Configurable を使用する傾向がありますか、それとも非シングルトン インスタンスを注入するためのより良い方法はありますか? それとも、ほとんどのユーザーは上記のようにファクトリ メソッドを作成しますか? エンティティの例は単なる例です。シングルトンではない他のオブジェクトがあり、通常は新しいものですが、注入が必要です。

これは、Guice のようなものでは別の方法で処理されますか? JSR-330 機能を使用するだけで、どのようにそれを行うでしょうか?

私は、ソーシャル ネットワーク データの消費を支援するフレームワークであるAgoravaのテクニカル リーダーです。

現在、Agorava は Java EE スタックでの使用を容易にするために CDI 上に構築されていますが、Android で動作するより軽量なソリューションを実現するために、Dagger を使用した実装を提供したいと考えています。

私の質問は、CDI と Dagger の実装の間で、共通の JSR 330 準拠のコードを共有できますか? つまり、Dagger を使用して、JSR 330 アノテーションを付けた jar にコードをコンパイルし、ソース コードを拡張したり、Dagger 固有の Jar でこのコードを使用したりすることは可能@Providesです@Modulesか?

答えが「いいえ」の場合、一般的な JSR 330 jar を Dagger コンパイラでコンパイルし、それを CDI 実装で使用することに問題はありますか? より正確には@Inject、修飾子やその他の JSR 330 仕様は実行時に引き続き利用可能であり、これらのアノテーション コードを持つクラスは Dagger コンパイラによって変更されないままになりますか? 最後に、Dagger で生成されたコード (クラス名、注釈) に、CDI がそれを検出して無視できるようにする一種のトラッカーがありますか?

私は以前に Spring DI を使用したことがあり、Spring を使用せずに Spring Bean クラスをテストできることが利点の 1 つとして認識されています (簡潔にするためにインポートは省略されています)。

現在、私は JSR-330 を試しています。これは、セッターを明示的に記述しないことを意味します。

これまでのところ、Hk2 を使用しています。これは、純粋に、Jersey が Hk2 に関連付けられており、他の JSR-330 実装との共存が困難になっているという逸話があるためです。

@Inject アノテーションによってセッターが使用可能になるという魔法が起こることを半分期待していましたが、そうではありません。

• フレームワークを呼び出さずに、この種の注釈付きクラスを (便利に) テストするにはどうすればよいですか?
• それができない場合、移植可能な方法でフレームワークを呼び出すにはどうすればよいですか (つまり、テスト コードを Hk2、Guice などに緊密に結合せずに)。
• それができない場合、この方法で注釈が付けられたクラスをテストするための典型的でクリーンな方法は何ですか?