問題タブ [cdi]

JSFアプリでDIとインターセプターを使用するときに問題が発生します。

JSFイベントを監視し、初期データルックアップを実行するバッキングBeanがあります。JSFページでは、Beanは次のようにイベントリスナーとして登録されます。

Beanはかなり前向きで、基本的に次のようになります。

daoは適切に注入され、ここまではすべて問題ありません。ここで、インターセプター内で実行される遅延読み込みを実行したいと思います（インターセプターが呼び出しコンテキストで続行するときに同じ動作が表示されるため、特定のコードは重要ではありません）。したがって、performSomeStuff（）を呼び出す前に、すべてのデータがロードされていることを確認したいと思います。

この時点で、EJBは注入されなくなります（NPEが表示されます...）-これに関するアイデアはありますか？

設定：

• GlassFish 3.0.1
• WELD-000900 1.0.1（SP3）
• クロサギ2.0.2（FCS b10）

前もって感謝します！

よろしく、アレックス

複数のJSF2.0セッションスコープのバッキングBeanでCDIイベントを監視できるかどうか疑問に思っています。イベントを観察することで、イベント/データを複数のセッションにプッシュできると思いました。

ユーザーがページ上のボタンを使用してイベントを発生させることができる小さなテストを設定しました（これは、実際にイベントを発生させるセッションスコープのバッキングBeanのメソッドに関連付けられています）。2つの異なるブラウザーを開くと、2つのセッションが作成され、イベントが各セッションスコープのバッキングBeanに通知すると思いました。

ただし、小さなテストを実行し、ボタンをクリックしていずれかのブラウザーでイベントを発生させると、イベントがセッションスコープのBeanの1つにのみ通知することがわかります。イベントが発生したBeanにのみ通知します（つまり、ブラウザー1のボタンをクリックすると、ブラウザー1のセッションを支援するセッションスコープのBeanが通知され、ブラウザー2のボタンをクリックすると、セッションを支援するBeanが通知されます。ブラウザ2に通知されます）。

イベントがすべてのBeanインスタンスに通知するという印象を受けました。ただし、そうではないようです。私はこれを行うことができるべきですか？セットアップが間違っていますか？

私のコードがどのように見えるかを示すために更新します：

イベントを発生させ、セッションスコープのデータを表示するためのjsfpage.xhtmlのスニペット：

イベントを受信するセッションスコープのBean：

イベントを発生させるアプリケーションスコープのBean：

JSF2 ページで同じ CDI Named Bean の複数のインスタンスを使用したいと考えています。(contentmanager カテゴリにアクセスするためのバッキング Bean があるとしますが、同じ JSF ページに複数のカテゴリを表示したいとします) @Named アノテーションのデフォルト名をどのように「オーバーライド」して、それらの 3 o 4 インスタンスを持つことができるのでしょうかマイページで。(¿ ページで Bean を使用するための古い JSP "useBean" タグを思い出してください... この方法で同じクラスの複数のインスタンスを使用できます) beans.xml について検索しましたが、見つかりません。古い faces-context.xml の「マネージド Bean」エントリを使用できますか? それが CDI @Named Bean に適用されるのか、それとも古い非 CDI 管理 Bean にのみ使用できるのかはわかりません。

情報をありがとう、イグナシオ

CDI には、@ApplicationScopedおよび ( javax.inject)@Singleton疑似スコープがあります。それらの違いは何ですか？@ApplicationScopedプロキシされていることとそうでないことのほかに@Singleton。

@SingletonBean をに変更できます@ApplicationScopedか? @ApplicationScopedBean は 2 つ (またはそれ以上) のインスタンスを持つことができますか?

同じセッションにSessionScopedCDIBeanのインスタンスが2つあります。CDIによって生成されたインスタンスは1つであるという印象を受けましたが、2つ生成されました。CDIがどのように機能するかを誤解していますか、それともバグを見つけましたか？

Beanコードは次のとおりです。

Faceletコードは次のとおりです。

デプロイメントとページへのナビゲートからの出力は次のとおりです。

GlassFish3.0.1の使用

handleNavigation()メソッドによってビューをリダイレクトすると、長時間実行される会話の伝播に問題があります。これが私のテストコードです：

私はconversationscoped豆と2つのビューを持っています：

conversationStart.xhtmlブラウザでURLを使用して呼び出されます

http://localhost/tests/conversationStart.jsf?paramTestId=ParameterInUrl

パラメータはに書き込まれbeanfield、ビューに正しく表示されます。次のビューに移動するには、3つの異なる可能性があります。3つすべてが正常に機能します。次のbeanfieldビュー（conversationLogin.xhtml）も表示されます：

ボタンをクリックしてスタートページに戻ると、会話Beanにはまだすべての値が含まれています。だからすべてが大丈夫です。これがBeanです：

今問題が来る！

preRenderViewBeanのメソッドでページをリダイレクトしようとすると（メソッドのコードのコメントを解除するだけで）、handleNavigation()すでに作成されているインスタンスを使用する代わりに、次のビューでBeanの使用が再度作成されます。cidパラメータは次のビューに伝播されますが！

誰かが何が悪いのか考えていますか？

よろしくトーマス

JBoss 6 Final にデプロイされた大規模な Java EE 6 アプリケーションに取り組んでいます。私の現在のタスクには、@EJB の代わりに一貫して @Inject を使用することが含まれていますが、いくつかのタイプの Bean、特に @MessageDriven Bean と @Scheduled メソッドを使用した Bean でいくつかの問題に遭遇しています。

タイミング (@Schedule の場合) が不運な場合、または起動時に MDB のキューにメッセージがある場合、注入されたリソース (EJB 自体) がまだバインドされていないため、Bean のインスタンス化が失敗します。 .

@Inject を使用しているため、コンテナー自体は @Inject を気にしないため、EJB コンテナーは Bean の準備ができていると見なしていると推測します。おそらく、@EJB インジェクションがないため、Bean を使用する準備ができていると想定しているだけです。注入するリソースがまだ実際にはバインドされていないため、注入された CDI プロキシは失敗します。

小さな例:

上記の例は、Bean が 2 つしかないため、頻繁に失敗することはありませんが、私が取り組んでいるプロジェクトでは多くの EJB がバインドされ、問題が増幅されます。ただし、MySupportingBean が最初にバインドされるという保証がないため、失敗する可能性があります。また、MySupportingBean がバインドされる前に onTimeout が呼び出されると、MyScheduledBean のインスタンス化が失敗します。代わりに @EJB を使用した場合、MyScheduledBean は、MySupportingBean への依存関係が満たされるまでバインドされません。

この例は onTimeout 自体では失敗しませんが、CDI が MySupportingBean を注入しようとしたときに失敗することに注意してください。

私はさまざまなフォーラムで、@Inject が常に優れていると多くの人が主張する多くの投稿を読みました。一般的には同意しますが、@Inject と組み合わせた @Schedule または @MessageDriven をどのように処理しますか? 私の経験では、そのような場合に Bean が機能するかどうかは運次第であり、EJB がデプロイされる順序と @Schedule または onMessage が呼び出されるタイミングに応じて、Bean は任意に失敗します。

Glassfish 3.0.1を使用しています...別のアプリケーションのEJBにリモートでアクセスするWebアプリケーションがあり、EJBを含むリモートアプリケーションが再デプロイされると、javax.ejb.NoSuchEJBExceptionが発生します（以下のスタックトレースを参照）。

これはうまくいかないのですか？問題のEJBが、まったく同じJNDI名を使用して正常にデプロイされたことがわかります。

Webアプリケーションを再起動する以外にこれを修正する方法はありますか？スタックトレースの元となるこの特定の例では、BeanにCDIを挿入するサーブレットにアクセスしていることに注意してください。

インジェクションは、適切なEJBを取得するために、次のプロデューサーを使用して実行されます。

プロデューサは、サービスをプロキシでラップしやすくするため、およびEJBの検索方法を簡単に変更できるようにするために使用されます。

StatusServiceのインターフェースと実装は次のとおりです。

編集：私自身の可能な解決策を提供しました。より良いものはありますか？

完全なスタックトレース：

Java Web アプリケーションでロガーを使用したいと考えています。

私は JBossAS 6.0.0.final、cdi (weld)、jsf などを使用しています。Seam はんだは、jboss-logging api を使用して具体的な実装 (slf4j、log4j など) に関連付けられていない抽象ロガーを使用することを提案しています。

コードでこのロガーを取得するには、次のように記述する必要があります

seam-solder.jar には、このロガーのプロデューサーがあります。

アプリケーションをデプロイすると、エラーが発生します

これは、seam-solder.jar に META-INF/beans.xml ファイルがなく、cdi コンテナーに必要なためです。

beans.xml ファイルを seam-solder.jar に手動で追加すると、アプリケーションは正常に動作します。

ハックなしで行う方法は？

アプリケーションを構築するためにmavenを使用しているため、私のソリューションは快適ではなく、うまくいきません。

PS: 以前のweld-extensions プロジェクトには、jar 内の META-INF/beans.xml ファイルが含まれていました。

この 2 つがどのように相互作用し、その境界がどこにあるのかを理解するのに苦労しています。それらは重複していますか？それらの間に冗長性はありますか？

両方に関連付けられた注釈があることは知っていますが、両方の簡単な説明を含む完全なリストを見つけることができませんでした。これが、それらの違いや重複する場所を明確にするのに役立つかどうかはわかりません.

本当に混乱するだけです。私は、EJB をかなりよく理解していると思いますが、CDI がテーブルにもたらすものと、CDI が EJB が既に提供しているものにどのように取って代わるか、または強化するかを正確に理解するのに苦労していると思います。