2016-07-04 25 views
1

私はRESTfulなサービスをテストする必要があります。私はすでにサービス用にJerseyを使用しているので、Jersey Test Frameworkを使用するのが最も適切な方法だと思いました。JerseyTestの不満依存関係(Dependency Injection)

しかし、簡単なテストを実行すると、サービスで使用しているDAOの実装が見つかりません(DI経由で設定されているため)UnsatisfiedDependencyExceptionが表示されます。 pom.xml Maven設定ファイルを変更するたびに、このエラーが発生していました。ほとんどの場合、依存関係を追加または削除していました。おそらく私が使用しているIDEは、IntelliJ IDEAが自動的に成果物を再生成することになっていますが、この依存関係の失敗を避けるために、旧式の成果物をTomcatサーバーの展開オプションとプロジェクト構造から削除する必要がありました。それをもう一度追加します。

ここでの問題は、テストフレームワークが別のサーバーを使用していることです。私は次の1つを使用しています:

私は別のサーバーを使用している場合、依存関係の問題を解決する方法がわかりません。

例外スタックの一番上のエラーメッセージは言う:

org.glassfish.hk2.api.UnsatisfiedDependencyExceptionを:注射のために利用可能な オブジェクトは、任意のアイデアはSystemInjecteeImpl

ではありませんでしたか?

編集。私はそれを汚れた解決策でパッチしました。

まず、私はDAOを注入したかをお見せしましょう:

// Binder.java 
public class Binder extends AbstractBinder { 
    @Override 
    protected void configure() { 
     bind(TournamentDao.class).to(ITournamentDao.class).in(Singleton.class); 
    } 
} 

// DependencyInjectionFeature.java 
@Provider 
public class DependencyInjectionFeature implements Feature { 
    @Override 
    public boolean configure(FeatureContext context) { 
     context.register(new Binder()); 
     return true; 
    } 
} 

// EventSchedulerService.java 
@Path("eventscheduler") 
public class EventSchedulerService { 
    private ITournamentDao dao; 

    @Inject 
    public EventSchedulerService(ITournamentDao tournamentDao) { 
     dao = tournamentDao; 
    } 
} 

Web構成ファイルweb.xmlこれらのクラスが配置されているパッケージをスキャン(パッケージには、テスト1よりも、同じ名前を持ちます存在する)、それが@Provider注釈を見つけたので依存性注入を実行する。

私はテストクラスでまったく同じことでした私の問題にパッチを適用するには:今、私は重複したコードを持っているので、

public class EventSchedulerServiceTest extends JerseyTest { 
    protected Application configure() { 
     ResourceConfig config = new ResourceConfig(EventSchedulerService.class); 
     config.register(new AbstractBinder() { 
      @Override 
      protected void configure() { 
       bind(TournamentDao.class).to(ITournamentDao.class).in(Singleton.class); 
      } 
     }); 
     return config; 
    } 
} 

は明らかにこれは悪い考えです。それはトリックでした。私はテストサーバーがサービス構成を正しく使うようにする方法を知りたいです。

答えて

0

これまでの説明のin the comments hereから、メインアプリケーションの設定にResourceConfigを使用しないという問題がありました。代わりにweb.xmlを使用します。

あなたは@ProviderでアノテートFeatureを使用している理由は、我々がFeature@Providerを拾っスキャン

​​

パッケージをweb.xmlに、パッケージスキャンを使用しているということで、それを自動的に登録します。このプロバイダーは、Binderを登録するために使用されます。これは依存関係注入を構成したものです。

前述のように、JerseyアプリケーションはResourceConfigまたはweb.xmlで設定できます。 web.xmlでできるジャージ設定は、ResourceConfigでもできます。あなたはちょうどあなたがまた、あなたがウェブでやっているのと同じ方法でスキャンをパッケージ化することができますregister

config.register(new DependencyInjectionFeature()); 
  • を呼び出すことができますResourceConfig

    • でコンポーネントを登録することができますさまざまな方法の束があります。 XMLは、packages

      config.packages("your.packages.to.scan"); 
      
    • を呼び出すことによって、あなたはまた、の実装をご覧くださいクラス。それはAbstractBinderを拡張します。あなたが現在あなたがAbstractBinderインスタンスを登録するテスト

      config.register(new AbstractBinder() { 
          @Override 
          protected void configure() { 
           ... 
          } 
      }); 
      

      でDIを設定する方法を見。だから、

      config.register(new Binder()); 
      

    だから、あなたはいくつかのオプションを持っているあなたを呼び出すとResourceConfigregisterを呼び出すDIの設定を登録することができますので、あなたの代わりに別のバインダを登録するだけBinderクラスのインスタンスを登録することができることを知っています。

  • +0

    私は今理解しています。だから基本的に私はテストで使用されるサーバーを "メイン"サーバーと同じ方法で構成する必要があります。したがって、各 '@ Provider'に対して私はちょうど' register() 'する必要がありますか?たとえば、私はカスタム例外マッパーを持っています。しかし、私はいくつかの例外を抱えているが、同じ振る舞いに到達するためにはどのように設定するべきか? – dabadaba

    +0

    同じこと。同じ方法でマッパーを登録することができます。パッケージスキャンや 'register'メソッドによる明示的登録 –

    +0

    しかし私は404エラーのためのマッパーを持っていません。私はそれがデフォルトのジャージーの振る舞いとして組み込まれていると思う。 'NotFoundException()'を投げると、自動的に404応答が生成されます。しかし、私のテストでは、コード500で応答しています。 – dabadaba

    関連する問題