私は現在、JUnit で EJB 3 サービスをテストするためのソリューションに取り組んでいます。(はい、ejb3unit を見てきましたが、うまくいきません。はい、openEJB を使用したコンテナー統合テストを見てきましたが、どちらもうまくいきませんでした..)
だから私の質問は、@EJB 注釈付きの依存関係を解決する方法は何ですか? Weld、Guice、Spring などの DI フレームワークを使用するという意味ではありません。このソリューションは、JBoss、Glassfish、openEJB などの EJB コンテナを使用せずに、単純な古い JUnit テストに適用できるはずです。
@PersistenceContext を介したエンティティ マネージャーの注入を、Java リフレクションを使用したちょっとしたハックに置き換えることができました。では、@EJB アノテーションを使用した依存関係に対してどのようにすればよいでしょうか?
（依存関係ツリーを自分で構築して解決することは気にしません。アイデアを探しているだけです;））
ドイツからのご挨拶、ps
あなたが提案した解決策に反対する理由がわかりません。
私はArquillianのようなものを提供しようとしていましたが、コンテナーを関与させたくないでしょう。
いくつかのアイデアに移る前に、コンテナが必要ない理由を確認したいだけです (テストはしていませんが) -
JBoss AS 7.x を使用すると、エンタープライズ アプリケーション サーバーの展開時間が大幅に短縮さ
れました。 Arquillian にはデプロイ API があり、何をデプロイするかを決定できることに言及してください (つまり、特定のテストに対して 1 つの Bean だけをデプロイするなど)。
しかし、私はあなたの質問を尊重しますので、ここにいくつかのアイデアがあり
ます.
あなたの豆にも同じことを適用してみませんか？B. A で問題が発生した場合は、たとえばcglib
に基づいて独自のインジェクション コードを開発してみませんか(インターフェイスだけでなく、クラス用の Proxy を作成するため)。
このようにして、クラスのオブジェクトが作成さ
れるときに、デフォルトの CTOR をインターセプトし、@Ejb で注釈が付けられたフィールドをスキャンできます。
各 Bean インターフェースに適切なクラスをインスタンス化する方法をマップする何らかの構成ファイルを使用し、このフローを再帰的に実行することをお勧めします (注入された Bean には @EJB アノテーションを持つフィールドもある可能性があるため)。
この作業方法を使用することにした場合は、ある種の「小さな依存性注入フレームワーク」を実装することに注意してください-個人的に私があなたのコードを見ることに興味があるという事実に加えて(:))慎重にすべきだと思いますなぜ「既成の解決策」を使いたくないのか考えてみてください。
JBoss、GlassFish、または OpenEJB などの EJB コンテナーが必要な Arquillian の提案について注意してください。
すべての依存関係を見つけて含めるだけで問題が発生する場合は、EJB Lite に必要なすべての依存関係が含まれている次の jar を試してください。
http://repo1.maven.org/maven2/org/apache/openejb/openejb-lite/4.0.0/openejb-lite-4.0.0.jar
それをテスト クラスパスに含めて (他の jar は必要ありません)、埋め込みコンテナーを起動します。
EJBContainer container = EJBContainer.createEJBContainer();
MyBean bean = (MyBean) container.getContext().lookup("java:global/myModleName/MyBean");
作業例はこちら
アルキリア星人を見たことがありますか？すべてのドキュメントはプロジェクトページにあります：http ：//www.jboss.org/arquillian.html