問題タブ [cdi]

ConversationScoped Bean を ViewScoped Bean に注入することはできません。 ConversationScoped Bean が ViewScoped Bean よりも寿命が短いか、またはその逆になる可能性があるためです。

この制限を克服するために、f:event を使用して preRenderView リスナーとしてインジェクションを実行しようとしました。

ただし、リスナーのinitializeTaskもゲッターのgetWorkPackageも呼び出されていません。

FacesContext を使用してマネージド Bean を別のマネージド Bean からルックアップできることはわかっていますが、なぜこれが機能しないのか興味があります。別のビューからビューに移動するときに f:event リスナーが呼び出されないためですか? すなわち。リダイレクトまたはダイレクト ページ ビューなしで?

Seam 3 Faces の s:viewAction タグも試しましたが、うまくいきませんでした。どちらも呼び出されません。

前もって感謝します。

これが Weld や Glassfish のバグなのか、それとも単に間違ったことをしているのかはわかりません。

api、impl、base の 3 つの jar があります。これらの jar は、Glassfish 3.1 (b37) にデプロイされる war にパッケージ化されています。結果は、impl 内の pojo で注入ポイントが満たされていないことを示すエラーです。注入に失敗した pojo はベース jar にあります。興味深いのは、同じ失敗した pojo を大騒ぎせずにバッキング Bean に注入できることです。また、昔ながらの new キーワードを使用して、注入依存関係を手動でインスタンス化することもできます。

何かご意見は？誰かが興味を持っている場合は、これを複製するMavenベースのテストプロジェクトもあります。

すべての jar には META-INF に beans.xml があり、戦争にも beans.xml があります。

• ヴィル

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

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

CDI初挑戦です。Glassfish v3を使用しています。アプリをデプロイすると、次のエラーが発生します。

java.io.IOException: com.sun.enterprise.admin.cli.remote.RemoteFailureException: アプリのロード中に例外が発生しました: org.glassfish.deployment.common.DeploymentException: java.lang.IncompatibleClassChangeError: com.example.arizona.client. ArizonaService と com.example.arizona.client.ArizonaService$App が InnerClasses 属性で一致しない

com.fuhrer.idea.glassfish.server.GlassfishServer3.doParseResponse(GlassfishServer3.java:28) com.fuhrer.idea.glassfish.server.GlassfishServer3Base.parseResponse(GlassfishServer3Base.java:156) com.fuhrer.idea.glassfish .server.GlassfishServer3Base.invoke(GlassfishServer3Base.java:127) com.fuhrer.idea.glassfish.server.GlassfishServer3Base.handleDeployment(GlassfishServer3Base.java:78) com.fuhrer.idea.javaee.server.JavaeeServerInstance$2.run( JavaeeServerInstance.java:131)

インジェクションやその他の CDI 機能はまだ実際には使用していません。これは、依存関係を整理しようとしているだけです。

私はGlassfishとCDIを注入に使用していますが、（ほとんど）正常に使用しています。Quartzジョブをインジェクションで動作させることができないようです-注釈が付けられたBeanはインジェクションされ@Injectません。

Quartzは、インジェクションの発生を防ぐ、ある種の異なるクラスローダーを使用していますか？

私は自分のweb.xmlでQuartzをそのように構成しています：

私のquartz.propertiesは次のようになります：

Java EE 5 の Web アプリケーションに取り組んでいます。いつか EE 6 にアップグレードできるかもしれませんが、現時点ではできません。Web アプリは Tomcat 6 で実行されています。CDI を使用できますか?

Weld のドキュメントに、セッション Bean を使用できないというメモがあることに気付きました。

There is a major limitation to using a servlet container. Weld doesn't support deploying session beans, injection using @EJB or @PersistenceContext, or using transactional events in servlet containers. For enterprise features such as these, you should really be looking at a Java EE application server.

@SessionScopedこれは、注釈を使用できないということですか? もしそうなら、それは現時点でCDIを使用するためのショーストッパーになるでしょう.

何かご意見は？ありがとう。

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 つのクラスがあるとします。1 つ目は、プロパティ、フィールド、または注釈のないクラスです。

そして、次のように B を注入するクラス:

クラス A は、使用するまではほとんど役に立たないため、2 つのオプションがあります。

• @注入する
• 信頼できる「new A()」を使用して、手動で構築します

A が注入された場合、CDI はそれを管理し、@Dependent の暗黙的なスコープを持つ B を注入するのに十分親切です。かっこいい、まさに私が欲しいもの。

ただし、手動で A を作成すると (たとえば、ファクトリまたはビルダーで)、CDI はオブジェクトを完全に無視し、タイプ B のオブジェクトを挿入しません。

私が話している例は、それが機能しない場合です。ここでは、オブジェクト a は常に null のままです。

なぜこれが機能しないのですか？

クラス A は有効なマネージド Bean であり、クラス B と同様に有効なスコープを持っています。静的メソッドに @Producer を追加しても、何も変更されません (これは問題ありません。静的メソッドの考え方は、 Builder をどこにも注入しないでください)。