問題タブ [jboss-weld]

現在、ステートレス 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

ありがとう。

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

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

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

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

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

豆：

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

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

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

私はこの理想主義を達成したいと思います：

1. SpringまたはWeldのみを使用し、両方は使用しないように、JSFBeanコンテナーの実装を1つだけにする。現在、バックエンドにSpringを使用しているので、Springが好きです。
2. アノテーションを1つだけ持つには、@ ManagedBean、@ Named、@Modelから選択します
3. @ RequestScoped、@ SessionScoped、@ ViewScoped、@ FlashScoped、おそらく@ConversationScopedなど、サポートされているすべてのスコープを使用できるようにするには
4. JSF Beansには、おそらく@Injectまたは@Autowiredを使用して、Spring-Managed-Services（バックエンドサービス）を注入できます。

これまでのところ、これらを達成するための最良の組み合わせを見つけていません。私が知る限り、間違っている場合は訂正してください。

1. @ManagedBeanはスプリングサービスで注入できませんか？
2. @Namedは@Injectを使用してSpringサービスを注入できますが、@NamedはWeldを使用しています。Weldの代わりにSpringを使用して@Namedを管理できますか？
3. @Namedは@ViewScopedとFlashScopeをサポートしていませんか？

あなたの考えや経験を共有してください。

ありがとうございました ：-）

2011年3月15日更新

JSR299CDI実装としてJbossWeldをSpringに置き換える方法を説明する興味深いページを見つけました。つまり、基本的に、質問番号2に回答します。スプリングサービスを注入できるようになったので、1番も間接的に答えられます。

しかし、それでも、3番目の質問は残っています。この記事のように、@Namedで@ViewScopedとFlashScopeを使用できると非常に役立ちます。Flashスコープの実装はまだ確認されていませんが、これまでに入手できる最も近いものはこのページです。

うまくいけば、jsr 299の実装で溶接をばねに置き換えることで、@ConversationScopedを使用できるようになります。

今すぐテストする必要があります。幸運を祈ります:-)

2011年3月18日更新

@ Named、@ Injectを実行するには、溶接の代わりにSpring3を正常に使用します。重要なことは、faces-config.xmlでel-resolverを設定することです。

AFAIK、Spring 3は現在CDIをまだサポートしていないため、bye2@ConversationScoped。

スコープについては、@ Scope（ "request"）または@Scope（ "session"）を使用する必要がありますが、@ RequestScoped（javax.enterprise.context.RequestScoped）および@SessionScopedを使用する場合は、この記事から提供されるブリッジ。

この記事の春のScope（ "view"）は魔法のように機能します:-)

ただし、1つの問題が残っています。Scope（ "view"）-beans間でオブジェクトを渡す方法..幸運を祈ります！

アップデート

ああ..ついに完了..JSF2が提供するFlashを使用して変数を渡すことは、実際には魔法のように機能します。そのためにサードパーティの実装は必要ありません。

つまり、基本的には溶接なしで実行できますが、スプリングを使用すると、ビュースコープを含む一般的なスコープを使用して、ダンはフラッシュオブジェクトを使用してBean間を通過できます。

欠けているのは会話の範囲ですが、これはまだ私にとって大きな問題ではありません。うまくいけば、将来の春はこの会話の範囲をサポートすることができます。

乾杯 ：-）

JSF 2.0（RIはMojarra 2.0.4）およびCDIを備えたWebSphere7でSeamsolderおよびSeamFaces3を使用したいと思います。必要なすべての依存関係（Weld 1.1、JBoss Logging）を含めましたが、サーバーが次のように表示し始めません。

次のプロバイダーのいずれかを使用してBeanManagerを見つけることができませんでした：
org.jboss.seam.solder.beanManager.DefaultJndiBeanManagerProvider（11）、
org.jboss.seam.solder.beanManager.ServletContainerJndiBeanManagerProvider（10） `

pre-servlet3.0環境のSeam構成手順に従いました

リソース（BeanMananger）が欠落しているように見えたので、このサーブレットコンテナのWeld命令に従って、BeanManagerをWebsphereのjndiリソースとして設定しようとしましたが、これも機能しませんでした。

サーバーの起動中に例外を引き起こしているソースコードは、次のようにBeanマネージャを検索しようとします。

これまでに、Websphere7でSeam3とCDI1.0（またはWeld 1.1）を実行している人はいますか？ここで何が欠けていますか？

PS：JSF2.0は正常に動作しています。

CDI JSF 2 Beans + 会話スコープを利用するために Weld に切り替えました。

これが私のmaven依存関係です:

これが私の web.xml のエントリです:

すぐに気づいたことの 1 つは、Tomcat 7 を 2 回ほどリロードするだけjava.lang.OutOfMemoryError: PermGen spaceで、catalina.out ログ ファイルに表示されることです。

Weld を使用する前に、java.lang.OutOfMemoryError がなくても Tomcat 7 を 10 回以上安全にリロードできます。catalina.sh で Xmx オプションを増やすと役立つと思いましたが、私の経験ではそうではありませんでした。JAVA_OPTS=-Xmx1024m

これは正常ですか？

私は現在使用しています：

1. アパッチトムキャット7
2. JBoss Weld サーブレット 1.0.1-Final
3. 空のbeans.xml
4. <listener-class>org.jboss.weld.environment.servlet.Listener</listener-class>web.xml で

私は現在、単純なカウンター @ConversationScoped Bean をテストしています。意図は、会話スコープを開始した後、ボタンがクリックされるたびにカウンターをインクリメントし続けることです..

しかし、送信後、最初に会話を開始した後でも、Bean は常に再作成されるようです。

ここに私の単純な豆があります:

これが私の単純なjsfビューです：

最初のアクセスのログ ファイルは次のとおりです。

ビューが表示された後、ボタンをクリックすると、 catalina.out のこのログで例外がスローされます。

tomcat ログからの例外トレースは次のとおりです。

何がうまくいかなかったのですか？

ありがとうございました ！

JettyとWicketが組み込まれたスタンドアロンアプリケーションがあります。
注射にはCDIを使いたいのですが。

だから私はhttp://docs.jboss.org/weld/reference/latest/en-US/html/environments.html#d0e5286
を見つけ、これをプログラムで追加しようとしていますが、それは非常に複雑です。

どうすればコーディングできますか？

私が見つけた他の情報源は次のとおりです。

• http://osdir.com/ml/java.jetty.support/2007-02/msg00198.html
• http://docs.codehaus.org/display/JETTY/JNDI

これまでのところ：

必要なときに「機能させる」だけの WELD の機能を利用するために作成した汎用 EL プロデューサーがあり、戻り値の型が確実に一致するように型強制を関数に書き込んでいます。溶接注入点。

ここに私の問題があります: WELD は、注入ポイントの割り当て可能な型から解決します。つまり、注入ポイントが文字列の場合、文字列の戻り値の型を持つプロデューサーのみを探します。

型強制を処理し、正しく型付けされたオブジェクトを返す 1 つのプロデューサーが必要なため、これには問題があります。

クラッジとして、実際のプロデューサーにエイリアスする String プロデューサー メソッドがあり、型クラッジングのみを行います。

これは...少なくとも、オブジェクト型の注入ポイントを持つ状況に到達するまでは機能します。その時点で、@Typedを使用しても、すべてのkludgeメソッドとジェネリックプロデューサーALLが一致し、あいまいな依存関係の例外が発生しますプロデューサーについて。

これを回避する正気の方法はありますか、それとも WELD にすべての面倒な作業を任せるというこの考えをあきらめるべきでしょうか?

Request スコープを持つエラー処理 Bean からの、このプロデューサーの使用例を次に示します。この場合、RequestURI が厄介です。他の 2 つは、型指定された「kludge」メソッドが機能する必要があります。この特定の Bean (コードは含まれていません) の主な機能は、未処理の例外をキャッチし、電子メールで報告して、将来の改訂でより具体的なエラー処理を行うことです。ここでの基本的な使用例は、EL へのプログラムによるアクセスを簡素化し、値バインディングを使用して EL に書き戻すことを可能にすることですが、この特定のコードではそれは不可能です。

他の方法を使用して以下を実行できることはわかっていますが、それは重要ではありません。現実的には、特に JSF 2.0 によって導入されたいくつかのよりエキゾチックなスコープ (特に Flash スコープ) を扱う場合に、IMO でプログラムから EL に簡単にアクセスできるようにすることは良いことです。私のユースケースのほとんどはFlashスコープに関係していますが、ここで開示するのは安全ではなく、予測可能な型でも、それらのために書かれたクラッジが必要な型でもないため、このより一般化された方法が必要な理由.

ここに私の修飾子があります：

プロデューサー:

そしてエラー：