3

Glassfish 3.1.2.2、Java ee6 を使用しています。

クラスが CDI を使用してヘルパー クラスを取得するライブラリがあります。そのライブラリを使用するある特定のプロジェクトで、その CDI 依存関係をオーバーライドし、代わりにそのプロジェクトに固有の独自のヘルパー クラスをライブラリに強制的に使用させたいと考えています。ライブラリは自由に変更できますが、デフォルトでは、ライブラリの他のユーザーの動作が変わらないように、デフォルトのヘルパー クラスを使用する必要があります。

@Alternativeこれは、 CDI パターンの完璧なアプリケーションです。ヘルパー クラス API の Java インターフェイスを作成しました。ライブラリにはデフォルトの実装があり、 ;で<alternatives>タグを使用できます。beans.xml動作をオーバーライドしたいプロジェクトでは、その特定のプロジェクトの beans.xml でヘルパーの独自の実装を指定します。

それが機能しないことを除いて。CDI 1.0 (java ee6) のライブラリの外部にあるライブラリからの代替動作をオーバーライドすることは明らかに 不可能です。

そのため、外部プロジェクトの beans.xml で何を指定しても、CDI はライブラリで定義された Bean を選択し続けます。

プロデューサーを経由することを検討しましたが、CDI からプロデューサーに EntityManager をパラメーターとして渡して、それをヘルパー クラスに渡す方法がわかりませんでした。このプロジェクトでは、通常、@PersistenceContextアノテーションを使用して EntityManager を注入します。

外部プロジェクトからの CDI インジェクションをオーバーライドする方法についてのアイデアはありますか?

4

3 に答える 3

1

これを行うには、Portable Extension を作成できます。イベントを聞いて、自分のProcessAnnotatedTypeものに置き換えます。AnnotatedTypeこれを支援するために、Apache DeltaSpikeBeanBuilderクラスを使用できます。

于 2013-09-03T02:34:22.120 に答える
0

最後に使用した解決策は、LightGuard からの提案に関連しています。CDI 拡張機能があり、提案されているように processAnnotatedType() をオーバーライドします。

AnnotatedTypeただし、 （どうすればよいかわかりません）を 置き換える代わりに、そこで説明されている手法を使用します： http://docs.jboss.org/weld/reference/latest/en-US/html/extend.html #d0e4800

そして、ライブラリで定義された Bean を拒否します。

デフォルトの実装が拒否されたので、アプリケーションに独自の Bean を配置すると、それが CDI によって選択されます。

これを Arquillian 統合テストでも機能させるには、この呼び出しをアーカイブに追加する必要があります。

addAsServiceProvider(Extension.class, <CDI extension class name>.class)

javax.enterprise.inject.spi.Extensionリソースは Arquillian で有効である必要はありません ( SHRINKWRAP -266を参照)。

于 2013-09-03T08:48:04.227 に答える