ローカライズされた文字列を簡単に取得するために、任意のクラスに java.util.ResourceBundle を挿入できるプロデューサーを作成したいと考えています。私の ResourceBundle-Producer は次のようになります。

Locale と FacesContext のインジェクションが機能します (Seam 3 Alpha Source から対応するプロデューサーを取得しました)。残念ながら、ResourceBundle は Serializable ではないため、この方法で生成することはできません。ResourceBundle を使用する Bean を呼び出す JSF ページにアクセスしようとすると、Weld から次のエラーが発生します。

Caused by: org.jboss.weld.IllegalProductException: WELD-000054 Producers cannot produce non-serializable instances for injection into non-transient fields of passivating beans\\n\\nProducer\: org.jboss.weld.bean-/D:/Program Files (x86)/GlassFish-Tools-Bundle-For-Eclipse-1.2/glassfishv3/glassfish/domains/teachernews/applications/teachernews/-ProducerMethod-services.producers.ResourceBundleProducer.getResourceBundle()\\nInjection Point\: field web.PersonHome.bundle

ResourceBundleResolver を機能させる方法はありますか? または、同様の機能を実現する他のメカニズムはありますか? 前もって感謝します！

編集：

わかりました、ほとんど獲得できなかったポイントの一部を使用します ;) この問題の適切な回避策も受け入れます!

Producer の作成が機能しない別の例があります: FlashProducer です。Flash はシリアル化できないため、FacesContext-Flash も生成できません。

JSR-299 (CDI) はリソースの (残念ながら命名された) 概念を導入します: http://docs.jboss.org/weld/reference/1.0.0/en-US/html/resources.html#d0e4373

You can think of a resource in this nomenclature as a bridge between the Java EE 6 brand of dependency injection (@EJB, @Resource, @PersistenceContext and the like) and CDI's brand of dependency injection.

The general gist seems to be that somewhere (and this will be the root of my question) you declare what amounts to a bridge class: it contains fields annotated both with Java EE's @EJB or @PersistenceContext or @Resource annotations and with CDI's @Produces annotations. The net effect is that Java EE 6 injects a persistence context, say, where it's called for, and CDI recognizes that injected PersistenceContext as a source for future injections down the line (handled by @Inject).

My question is: what is the community's consensus--or is there one--on:

• what this bridge class should be named
• where this bridge class should live
• whether it's best to localize all this stuff into one class or make several of them

...?

Left to my own devices, I was thinking of declaring a single class called CDIResources and using that as the One True Place to link Java EE's DI with CDI's DI. Many examples do something similar, but I'm not clear on whether they're "just" examples or whether that's a good way to do it.

Thanks.

すべてのサービスなどを保持する中央の溶接コンテナが欲しいのですが。ただし、このコンテナは、ローカル設定を含む2番目のコンテナによってラップされます。目標は、外部コンテナーに依存関係が見つからない場合、内部コンテナーを検索したいと思います。

どうすればこれを達成できますか？非標準のWELD拡張機能の使用に戻らずに、スタンドライクな方法で物事を実行したいと思います。

Guiceが、コードで独自のバインディングを実行して独自のモジュールを手動で作成する方法が気に入っています。一方、CDIは、sestバインディングへのプログラムによるアクセスではなく、魔法に依存しているようです。私は間違っていますか、またはWELDで同じ効果をどのように達成できますか？

コードサンプルをいただければ幸いです...

明確化

http://code.google.com/p/google-guice/でGuiceによって提供されたビルダーパターンスタイルを使用して、プログラムでモジュール（Guice用語申し訳ありませんがCDI用語がわかりません）を構築したいと思っていました。

私は動的システムを構築していますが、Weldがクラスパスなどを動的にスキャンして型を見つけて登録するのではなく、型（インターフェイスなど）や定数などをバインドできるようにする必要があります。CDIは静的であると思います。javax.injectパッケージには、プログラムで型を実装にバインドできるインターフェースは含まれていません。

明確化パート2

元の質問の基本的な前提は、注釈が焼き付けられており、イネクターを支援するために注釈に定義されているルールを変更できないという単純な観察でした。私は当初、CDIクラスパススキャナーが内部使用の定義を構築するために使用するのと同じインターフェイスへのパブリックアクセスを望んでいました。基本的には、アノテーションを読み取ってコンテナーの定義を作成できるレイヤーが必要です。デフォルトのプロバイダーは、現在行われていることを実行するプロバイダーである可能性がありますが、他の戦略が必要な場合は、これを実行する可能性があります。

現在のアプローチの問題の1つは、異なるアノテーションを持つコンポーネント（クラス）を再利用して異なるコラボレーターを選択できないという制限です。ジャンプする前に、このステートメントを修飾させてください。そうです、プロバイダーなどで実行できますが、これにより、より多くのアーティファクトが発生します。もっと簡単な方法があるはずです。

例1

この例が不十分な場合は申し訳ありませんが、私のユースケースははるかに複雑であり、詳細が邪魔になり、はるかに長く読むことができます。

引数のために次のようないくつかのパラメータを持つURL書き換えコンポーネントがあると想像してください

• このパターンをそのパターンに置き換えます。
• 多分htmlクリーナー

この同じコンポーネントに2つの異なる置換ルールを注入したいが、htmlクリーナーインジェクターを使用したい場合は、行き詰まります。確かにこれを回避する方法はありますが、もちろんより多くのコードであるアーティファクトが必要です。

残念ながら、すべてのバインディングルールはインスタンスではなくクラスにあるため、クラスを要求するたびに、機能的に同等のインスタンスが返されます。

溶接

この質問は少し前に書かれたもので、Weldをあきらめました。魔法がどのように行われるかを指示する方法は間違っていると思います。いつ、どのようにこのアクションを繰り返したいかを制御する方法を提供せずに、これがどのように発生するかを彼らが私に指示するという事実は好きではありません。私はこの柔軟性の欠如が好きではありません。

アプリケーション スコープのコンポーネントがいくつかあります。現在の環境に応じて、どちらか一方をインストールしたいと考えています。JBoss Seam では、@Install(false) を使用してから、必要な Bean を components.xml で構成します。

CDI / WELDでこれを行うための同様の方法はありますか?

ありがとう、

ウォルター

Seam 2を利用したアプリケーションをCDIに移行していますが、保持することが重要なことの1つは、エラー処理です。Seam 2では、デフォルトの例外ハンドラーを自分のものに置き換えただけですが、CDIでは、インターセプターを使用する必要があると思います。

インターセプターを使用すると、通話をインターセプトする場所を指定する必要があるため、これをどのように設定しますか？私は主に監査を実行したいので、例外が発生するとログに記録され、通知（電子メール、xmpp、SMS、電話）が管理者に送信されます。

例外が発生した場合、私が聞いて行動できるイベントはありますか？

ウォルター

[私の設定: Java EE 6 アプリケーション、EJB3.1、CDI/Weld、Glassfish 3.0.1 で動作する JSF2 を使用]

EJB3.1 の新しい @Asynchronous メソッドに関する記事をいくつか読みましたが、非同期メソッドの危険性や、実際に注意する必要があることについて言及した記事はありませんでした。

私のアプリでは、@Asynchronous E-Mail サービスを使用して、大量のメールを送信しています。このサービスを CDI/Weld Bean から呼び出しています。テスト中に ConcurrentModificationExceptions が頻繁に発生しましたが、今までのところ、クラッシュする場所と理由がよくわかりません。

私の Beans が大まかにどのように見えるかを示すために、重要な部分は次のとおりです。

私のCDI-Beanでは、このEJBを次のように使用しています(進行状況をJSF2に公開しています):

私は一般的に尋ねたかっただけです:私はここで何か完全に間違ったことをしていますか(スコープ、インジェクション、フューチャーの使用)? ConcurrentModificationExceptions を回避するために、@Asynchronous メソッドを使用する場合、何に注意する必要がありますか?

電子メールを EJB として注入しています。EmailEJB 全体を Asynchronous にして @Inject @Asynchronous で注入したほうがよいでしょうか? 違いは何ですか？

どんなヒントでも大歓迎です！

溶接ウィケットに問題があります。抽象クラスから継承する EJB を @Inject するときに、抽象クラスからメソッドを呼び出そうとすると、ejb-ref エラーが発生します。ただし、具象クラスからメソッドを呼び出すと、完全に機能します。メソッドをオーバーライドして呼び出すことができ、オーバーライドされたメソッドを抽象クラスに委譲することができ (オーバーライドされたメソッドが super.method() を呼び出す)、それが機能します。抽象クラスに対して何らかの構成を行う必要がありますか?

ありがとう。

私は Web アプリで Seam 2 (Java EE 6 の調査も開始) を使用しており、数日前に Seam の CDI が Weld を使用した SE アプリケーションで利用できることを知りました。Weld SEのWeld のドキュメント ページによると、セットアップは簡単です。そこで、単一クラスの HelloWeld、weld-se.jar、および log4j jar を使用して Eclipse プロジェクトをセットアップしようとしました。

新しい Java アプリケーション実行構成を作成org.jboss.weld.environment.se.StartMainし、メイン クラスとして示しました。プロジェクトを実行したとき、HelloWeld がまったく呼び出されていないことは驚くことではありませんでした。私が得たのは、Weld が正しく起動したことを示すいくつかのログ エントリだけでした。

それで、私は何が欠けていますか？

[更新: Glassfish フォーラム/ML でhttp://forums.java.net/jive/thread.jspa?messageID=480532で議論した後、Glassfish https://glassfish.dev.java.net/issuesに対してバグが報告されました。この問題については/show_bug.cgi?id=13040を参照してください。]

@Stateless EJB のローカルの非インターフェース ビューを JSF2 @Named @javax.enterprise.context.SessionScoped バッキング Bean に注入しようとしています。EJB は、抽象ジェネリック基本クラスを拡張するいくつかのクラスの 1 つです。「@Inject TheEJBClass varName」の挿入は、「ejb TheEJBClass の ejbRef をタイプ クラス my.package.name.TheAbstractBase のビジネス オブジェクトに変換できません」で失敗します。[編集: 実際には、インジェクションは成功しますが、スーパークラスから継承されたメソッドのインジェクトされたプロキシでのメソッド解決は失敗します。]「@EJB TheEJBClass varName」を使用すると、varName は null のままです。つまり、何もインジェクトされません。

詳細：

Linux (重要な場合は Ubuntu 10.04) で Glassfish 3.0.1 を実行していますが、CDI (Weld) を使用してデータ モデル EJB を JSF2 セッション スコープ モデルに挿入する際に問題が発生しています。はい、あなたが尋ねる前に、beans.xml が配置されており、CDI がアクティブ化されてインジェクションが実行されています。

@EJB アノテーションを挿入すると、次のようになります。

... EJB は実際には注入されず、memberName は null のままです。

CDI @Inject アノテーションを使用して注入すると、次のようになります。

...次に、TheEJBClass のスーパークラスに実装され、TheEJBClass 自体でオーバーライドされていない「memberName」のメソッドを呼び出すと、CDI が不平を言い、次のように報告します。

ベースを具象クラスに変換して非ジェネ化しようとしましたが、同じ問題が発生したため、一般的なベースで Weld バグにヒットしているとは思いません ( https://jira.jboss.org/browse /WELD-305、https://jira.jboss.org/browse/WELD-381、https://jira.jboss.org/browse/WELD-518 )。

わかりやすくするために注釈に完全なパッケージ修飾を追加したコードの概要は次のとおりです。

TheEJBClass で TheAbstractBase.getValue() をオーバーライドするか、スーパークラスではなく TheEJBClass で定義されたメソッドを呼び出すと、インジェクションが機能することに注意してください。問題は継承に関係しているようです。

JSF2 のビルトイン ライフサイクルとインジェクション機能を使用する非常によく似たコードが機能しましたが、これが新しいプロジェクトであり、CDI が将来に向かっていることを考えると、CDI を試すのが最善だと思いました。JSF2/EJB インジェクションの使用から始めたものは次のとおりです。

私は現在、自己完結型のテスト ケースの作成に取り組んでいますが、これが何かばかげたことをしているだけの場合や、Google-fu ではないよく知られている解決策がある場合に備えて、今すぐ質問を開始すると考えました。見つけるまでt。JSF2/EJB インジェクションでは機能するのに、CDI インジェクションでは失敗するのはなぜですか?

(Glassfish フォーラムにhttp://forums.java.net/jive/thread.jspa?threadID=152567として再投稿されたため)