問題タブ [cdi]

現在、ステートレス EJB を Jboss 6 AS Final の CDI マネージド コントローラーに挿入しようとしています。コントローラは、JSF ページからアクセスできるコンテキストで管理されます。ステートレス Bean を注入すると、@EJB動作します。ステートレス EJB を注入すると@Inject、次の例外が発生します。

私のコントローラー：

私のステートレス Bean:

Bean のインターフェースには @Local アノテーションが付けられます。

myTestManager を呼び出そうとすると、次の例外が発生します。

WELD-000079 JNDI で EJB が見つかりませんでした: class de.crud.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$usr$local$jboss$server$default$deploy$test$ ear"-SessionBean-TestManagerBean_$$_WeldProxy

ありがとう。

JSF と CDI を使用してシンプルなメニューを処理するベスト プラクティスを探しています。

動的エントリを含むトップ メニューが必要です。次のようなもの (メイン テンプレートから):

NavigationBean (Sessionscoped で、NavigationItems のリストを保持) と NavigationItem は単なる Bean です。次に、別のビューを開き、現在のビュー ID を navigatiobean 内で選択されているように設定します。

問題は、手遅れです。ページは既にレンダリングされており、ビュー ID が選択されていません。

このアプローチはまったく良くありませんか？ベストプラクティスはありますか? JSF メニューと JSF ナビゲーションを検索すると、別の問題が発生するため、何も見つかりませんでした。

前もって感謝します！

私は Glassfish で CDI をいじっていましたが、あまりうまくいきませんでした。/WebContent/META-INF に empyt beans.xml を配置するとすぐに、次のエラーが発生します。

モジュールの CDI_Example デプロイ エラーをデプロイできません: CDI_Example: アプリのロード中に例外が発生しました: org.glassfish.deployment.common.DeploymentException: WELD-001201 beans.xml URL のロード中にエラーが発生しました: null

Weld のドキュメントには、ファイルが空である可能性があると記載されていますが、Glassfish v3 はファイル内に何かを想定しているようです。

誰かがアイデアを得ましたか？

どうも

Weld コードのサンプルを示すチュートリアルはたくさんありますが、入門的な概要はありません。

紹介記事を提案するか、次の質問に答えてください。

• ウェルドはあなたに何をしますか？
• Java EE 6 との関係は?
• Java EE 6 プロジェクトでどのように使用しますか?
• Java EE 6 プロジェクトでそれを使用するとしたら、何に取って代わるのでしょうか?

シンプルなコマンドボタンがあります

次の単純なアクションリスナーを呼び出します

基本的に、クリックすると会話が終了し、新しいページにリダイレクトされるボタンが必要です...

これは1回だけ機能し、ログに次の情報が表示されるたびに機能します（ユーザーの観点からは、すべてが適切に機能しました。ボタンをクリックすると、リダイレクトが適切に機能します）

重大：java.util.HashMap $ EntryIterator.next（HashMap.java:834）のjava.util.HashMap $ HashMap $EntryIteratorのjava.util.HashMap$ HashIterator.nextEntry（HashMap.java:793）のjava.util.ConcurrentModificationException。 next（HashMap.java:832）at org.jboss.weld.context.AbstractConversationContext.deactivate（AbstractConversationContext.java:250）at org.jboss.weld.jsf.WeldPhaseListener.deactivateConversations（WeldPhaseListener.java:131）at org.jboss .weld.jsf.WeldPhaseListener.afterPhase（WeldPhaseListener.java:96）at com.sun.faces.lifecycle.Phase.handleAfterPhase（Phase.java:189）at com.sun.faces.lifecycle.Phase.doPhase（Phase.java ：107）com.sun.faces.lifecycle.LifecycleImpl.execute（LifecycleImpl.java:118）at javax.faces.webapp.FacesServlet.service（FacesServlet.java：312）org.apache.catalina.core.StandardWrapper.service（StandardWrapper.java:1534）at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter（ApplicationFilterChain.java:343）at org.apache.catalina.core.ApplicationFilterChain .doFilter（ApplicationFilterChain.java:215）at net.balusc.http.multipart.MultipartFilter.doFilter（MultipartFilter.java:78）at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter（ApplicationFilterChain.java:256）atorg。 apache.catalina.core.ApplicationFilterChain.doFilter（ApplicationFilterChain.java:215）at org.apache.catalina.core.StandardWrapperValve.invoke（StandardWrapperValve.java:279）at org.apache.catalina.core.StandardContextValve.invoke（StandardContextValve。 java：175）org.apache.catalina.core.StandardPipelineで。doInvoke（StandardPipeline.java:655）at org.apache.catalina.core.StandardPipeline.invoke（StandardPipeline.java:595）at com.sun.enterprise.web.WebPipeline.invoke（WebPipeline.java:98）at com.sun .enterprise.web.PESessionLockingStandardPipeline.invoke（PESessionLockingStandardPipeline.java:91）at org.apache.catalina.core.StandardHostValve.invoke（StandardHostValve.java:162）at org.apache.catalina.connector.CoyoteAdapter.doService（CoyoteAdapter。 ：326）org.apache.catalina.connector.CoyoteAdapter.service（CoyoteAdapter.java:227）at com.sun.enterprise.v3.services.impl.ContainerMapper.service（ContainerMapper.java:170）atcom.sun。 grizzly.http.ProcessorTask.invokeAdapter（ProcessorTask.java:822）at com.sun.grizzly.http.ProcessorTask.doProcess（ProcessorTask.java：719）com.sun.grizzly.http.ProcessorTask.process（ProcessorTask.java:1013）at com.sun.grizzly.http.DefaultProtocolFilter.execute（DefaultProtocolFilter.java:225）at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter （DefaultProtocolChain.java:137）at com.sun.grizzly.DefaultProtocolChain.execute（DefaultProtocolChain.java:104）at com.sun.grizzly.DefaultProtocolChain.execute（DefaultProtocolChain.java:90）atcom.sun.grizzly.http。 HttpProtocolChain.execute（HttpProtocolChain.java:79）at com.sun.grizzly.ProtocolChainContextTask.doCall（ProtocolChainContextTask.java:54）at com.sun.grizzly.SelectionKeyContextTask.call（SelectionKeyContextTask.java:59）at com.sun.grizzly com.sun.grizzly.utilの.ContextTask.run（ContextTask.java:71）。AbstractThreadPool $ Worker.doWork（AbstractThreadPool.java:532）at com.sun.grizzly.util.AbstractThreadPool $ Worker.run（AbstractThreadPool.java:513）at java.lang.Thread.run（Thread.java:662）

重大：WebModule [] PWC1322：ServletRequestListenerでrequestDestroyedメソッドを呼び出すときにエラーが発生しましたorg.jboss.weld.servlet.WeldListener java.lang.IllegalStateException：コンテキストがorg.jboss.weld.context.AbstractConversationContext.deactivate（AbstractConversationContext.java:263でアクティブではありません）org.jboss.weld.servlet.WeldListener.requestDestroyed（WeldListener.java:125）at org.apache.catalina.core.StandardContext.fireRequestDestroyedEvent（StandardContext.java:4588）atorg.apache.catalina.core.StandardHostValve。 postInvoke（StandardHostValve.java:243）at org.apache.catalina.connector.CoyoteAdapter.doService（CoyoteAdapter.java:328）at org.apache.catalina.connector.CoyoteAdapter.service（CoyoteAdapter.java:227）at com.sun .enterprise.v3.services.impl.ContainerMapper。service（ContainerMapper.java:170）at com.sun.grizzly.http.ProcessorTask.invokeAdapter（ProcessorTask.java:822）at com.sun.grizzly.http.ProcessorTask.doProcess（ProcessorTask.java:719）at com.sun .grizzly.http.ProcessorTask.process（ProcessorTask.java:1013）at com.sun.grizzly.http.DefaultProtocolFilter.execute（DefaultProtocolFilter.java:225）at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter（DefaultProtocolChain.java:137） ）com.sun.grizzly.DefaultProtocolChain.execute（DefaultProtocolChain.java:104）at com.sun.grizzly.DefaultProtocolChain.execute（DefaultProtocolChain.java:90）at com.sun.grizzly.http.HttpProtocolChain.execute（HttpProtocolChain。 java：79）com.sun.grizzly.ProtocolChainContextTask.doCall（ProtocolChainContextTask.java:54）atcom。sun.grizzly.SelectionKeyContextTask.call（SelectionKeyContextTask.java:59）at com.sun.grizzly.ContextTask.run（ContextTask.java:71）at com.sun.grizzly.util.AbstractThreadPool $ Worker.doWork（AbstractThreadPool.java： 532）com.sun.grizzly.util.AbstractThreadPool $ Worker.run（AbstractThreadPool.java:513）at java.lang.Thread.run（Thread.java:662）

依存関係を Bean に注入するように要求すると、そのリソースのインスタンスへのプロキシが注入されることをどこでも読んでいます。プロキシとは何か、メッセージを別のインスタンスに転送する方法を知っているインスタンスであることを知っていると思います。また、コンテナーがこのマネージド Bean にサービスを提供できるのは、このパターンであるとも述べられています。

これはよくわかりません。なぜプロキシが必要なのですか? そして、これはどのように実装されていますか？各 Bean にプロキシ オブジェクトはありますか? または、1 つのインスタンスに転送するプロキシが多数ありますか? それともどちらでもない？

また、GoF の本のデザイン パターンから、プレースホルダーとして機能するプロキシ クラスを提供する必要があることを読みました。しかし、Java EE では決してそれを行いません。アプリケーション サーバーは実行時にプロキシ クラスを作成しますか?

Weld または CDI の Conversation スコープを理解するのに問題がありました。

私のJSFファクレットページで私は呼び出します：

豆：

ブラウザを更新するたびに、新しい会話が開始されます。それは正しい振る舞いですか？では、なぜ会話は常に一時的なものなのでしょうか? 例外はスローされません。beans.xml が作成され、空になります。

このページは他の多くのページで使用されるため、別のjsfページにファセットを使用してjsfページを再利用しようとしています。しかし、問題は、このページに対応するマネージドBeanの属性を、このページを含むマネージドBeanに取得できないことです。

ページ、pessoa.xhtml、反復およびヘッダーコードの一部が削除されました：

@NamedマネージドPessoaMB

これは、pessoa.xhtmlを含むページの1つのコードです。empresa.xhtml

そして、@NamedマネージドBeanEmpresaMB。

@Named @SessionScoped publicclassEmpresaMBはSerializableを実装します{

@Injectアノテーションでうまくいくと思いますが、そうではありません。

推奨できる CDI/Weld に関する既存の、または今後出版される本はありますか?

Seam in Actionに範囲と品質が似ているものを探しています。これは Seam の優れたリファレンスでしたが、今では少し古くなっているようです。

EJB3.0に基づく新しいプロジェクトを開始しています。私は「春」ベースのバックグラウンドを持っている（そしてそれが大好きです）ので、私にとって緩い結合とテスト容易性は大きな必需品です。この投稿は「ejbvs.spring」に関するものであってはなりません。あなたがすでにこれで実際のプロジェクト経験を持っているならば、それは完璧でしょう。

問題を示すためのサンプルコードを次に示します。

クライアント->ejb->コラボレーター1->コラボレーター..->コラボレーターn

ejb 3.0ですべてのコラボレーターとそのコラボレーターに依存性注入を実装するための最良の方法を知りたいですか？この意味での共同作業者は、非常に小さな専用クラスである可能性があります。

これまでに次のオプションについて説明してきましたが、いつものようにまだ適切な結論は出ていません:)

1. ejb標準は、すべてがステートレスセッションBeanであり、すべての結果（プーリング、リソース処理など）でのみ使用されます。

2. ステートレスセッションBeanを「ビジネスコンポーネント」（エントリポイント）として使用し、それ以降

a）スプリングワイヤード依存関係（「jbosssnowdrop」統合による）

b）CDI有線依存関係（ejb3.0およびjbosseap 5.1のWELD経由）

単体テストでBeanをどのように使用できるかを知る必要はありません。私が求めている答えは、実行中のappserver内のすべての依存関係を接続するための最良のアプローチです（Spring vs. Guice vs. CDI vs.EJB）。外側のEJB（「ビジネスエントリポイント」）から下に向かってグラフを知る必要があるだけです。したがって、外部のすべて（サーブレット、フロントエンドなど）はこの質問の範囲ではありません:)

プロジェクトにEJB3.0とjbosseap5.1が設定されていると仮定してください:)

あなたの答えと、うまくいけばプロジェクトベースの知識を楽しみにしています。