問題タブ [jboss-weld]

私はWeld、JbossのCDIの実装を使用しています。永続化のための JPA/Hibernate。何か違うことのために、私は以前に使用したことのない Glassfish 3 にクラックを与えています。依存関係の管理に Maven を使用しています。

CDI にはすぐに使用できるトランザクション管理が含まれていないため、独自のモジュールを作成する代わりに、Seam 3 Persistence モジュールを使用することにしました。現在、これは現時点ではアルファ版のみであることを十分に認識しているため、問題が発生している可能性があります。他の誰かがこれを見て、それを修正するのを手伝ってくれるか、少なくとも私が問題を抱えている理由を教えてくれることを願っています.

したがって、永続化モジュールを追加する前に、すべてが正常にビルドおよび実行されます。アプリのホームページは問題なく開けます。しかし、Seam 3 永続化モジュールを pom.xml に追加すると、起動時にアプリケーションが例外をスローします。動作する場合と動作しない場合の唯一の違いは、pom.xml に追加している依存関係の 1 つです。

pom.xml に追加する依存関係は次のとおりです。

http://seamframework.org/Seam3/PersistenceModuleの指示に基づいて、この依存関係を追加しました。このページのドキュメントをクリックすると、他のいくつかの依存関係について言及されていることは承知していますが、それらを追加するときにも同じ問題が発生します。これは、私が問題を絞り込んだ依存関係です。

したがって、上記の依存関係を追加してサーバーを起動すると、起動時に次のようになります。

ご覧のとおり、実際に行うことはあまりありません。

以前にこの例外を見たことがありますか? 何が原因か分かりますか？最後に、それを修正する方法を知っていますか？

実行中のプログラムにマップの形式で外部構成を提供する状況があります。JSR-330 Dependency Injection は、マップを渡したり、JNDI を使用して取得したりする代わりに、コード内でその構成マップを使用するためのよりクリーンな方法を提供することを発見しました。

JSR-330 実装がこのフィールドに自動的に入力できるようにします。

Guiceを使用すると、値を設定できます

Weld でも同じことができるようにしたい (「server.username」を「foobar」などにバインドする) メカニズムはbeans.xml である可能性が最も高いことを理解していますが、単純な「このマップを Weld にフィードする」ことをお勧めします。 、してください」コードの代替。これを行うにはどうすればよいでしょうか。

@ProviderEDIT 2013-10-16: 実行時ではなくコンパイル時に動作する Dagger を調べたところ、通常、プログラムごとに 10 ～ 20 個の Dagger があるため、各構成文字列のメソッドを使用して、構成を検索することができることがわかりました。地図。これにより、メソッド固有の動作 (デフォルト値を含む)、javadoc を提供する機能、およびこれらすべてのメソッドを同じクラスに配置する機能が可能になります。また、すぐに使用できる Weld でもうまく機能します。ブログエントリでより完全な説明を書くことを検討しています。

Spring コンテキストで定義された Bean を CDI 管理コンポーネントに注入しようとしていますが、うまくいきません。Bean は注入されません。代わりに、注入が実行されるたびに新しいインスタンスが作成されます。私の環境は、JBoss Weld を使用した Tomcat 7 です。

Spring ApplicationContext は簡単です。

CDI マネージド Bean は次のようになります。

これは私のfaces-config.xml

ただし、testJSF ページ内からプロパティにアクセスTestすると、アクセスが発生するたびに新しいインスタンスが作成されます。これは簡単な例です:

次の出力が得られます。

リフレッシュ後:

最初の出力が正しいことがわかります。ページを頻繁に更新してもtestFromSpring、Spring コンテキストで定義された Bean から値が返されます。getTestただし、2 番目の出力は、コンポーネントのメソッドtestが呼び出されるたびにTest、Spring コンテキストのインスタンスを使用する代わりに、新しいインスタンスが作成されて注入されることを明確に示しています。

では、この行動の理由は何ですか？

Spring コンテキストから CDI マネージド Bean に Bean を注入するにはどうすればよいですか?

また、Spring コンテキストで定義された名前を使用して修飾子を使用しようとしましたが、Bean が見つからないことを示す例外がスローされました。

コードの

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 は任意に失敗します。

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 ファイルが含まれていました。

CDIをGWTと統合するための最良の方法は何ですか？特に、RemoteServiceServlet拡張機能に対して依存性注入を機能させる方法を知りたいです。どうやらCDIはjavax.servlet.Servletから派生したクラスでは動作しません。別の方法があれば、RemoteServiceServletを捨てることができてうれしいです。

GWTクライアント側ではDIは実際には必要ありませんが、正常に機能した場合は喜んで使用します。

ConversationScopedBean をサーブレットに注入する必要があります。標準の単純な@Injectタグを使用し、cid パラメーターを指定してサーブレットを呼び出しますが、注入された Bean でメソッドを呼び出すと、次のエラーが発生します。

org.jboss.weld.context.ContextNotActiveException:WELD-001303スコープ タイプのアクティブなコンテキストがありませんjavax.enterprise.context.ConversationScoped

これらの Bean をサーブレットに注入できますか、それとも、Session および Request スコープの Bean のみを注入できますか?

Java EE 6 の優れた点の 1 つは、新しい依存性注入フレームワーク (CDI と Weld 参照実装) です。凍結されたコア jar を追加し、コア jar の機能を置き換える新しいモジュールを提供する追加の jar を追加できます。

私は現在、Weld で上記の作業を行う過程にあり、率直に言って、カバーの背後で行われている魔法が多すぎます。機能するか機能しないかのどちらかであり、デフォルトでは何が起こっているかについてあまり役に立たないため、何が間違っているかを調査して修正できます.

次のようなことを簡単に有効にできるスイッチがあると思います。

• どのクラスパス エントリがスキャンされ、どこでスキャンされますか? 結果はどうでしたか？
• どのクラスのインジェクションにどの Bean を使用できますか?
• 特定の Bean が後で考慮されない原因は何ですか? 特定の瓶？

つまり、意思決定プロセスをもっと詳しく見る必要があります。なんらかの理由で、これは Guice では必要とされていません。おそらく、マジックがはるかに少なく、エラー メッセージが非常に優れているためです。

溶接アプリケーションをデバッグするために何をしますか? また、それはどの程度役立ちますか?

@ViewScoped一部の Web ページのバッキング Bean に対して、アプリケーションで - スコープを使用したいと考えています。また、CDI を使用して依存関係をバッキング Bean に注入します。

ただし、このように注釈が付けられたバッキング Bean を使用すると、

注釈は@Inject何も注入せずNullPointerException、依存関係にアクセスするとすぐに取得します。

ただし、バッキングビーンを装飾すると

注入は正常に機能しますが@ViewScoped、CDI / 溶接の一部ではないため無視されます。

@ViewScopedCDI Weld と併用するにはどうすればよいですか?

2晩以来、私は溶接CDIをJSF1.2を使用してEJB3.1アプリケーションに統合しようとしています。@NamedJSFページで注釈付きコントローラーを使用してを呼び出そうとしました。問題は、プロジェクトをデプロイするときに例外がスローされないことと、ページを呼び出すときに例外がスローされないことです。

簡単な例には、次のもののみが含まれます。

コントローラー：

そしてそれは呼び出しです：

THX