Javaの@RequestScopedでRuntime Exception？知っておくべきCDIの基本と解決策☕️

はじめに (対象読者・この記事でわかること)

この記事は、Java EE（現Jakarta EE）アプリケーション開発者、特にCDI（Contexts and Dependency Injection）を利用している方で、@RequestScopedアノテーションを使用する際に予期せぬRuntime Exceptionに遭遇した経験のある方を対象としています。

この記事を読むことで、@RequestScopedがRuntime Exceptionを引き起こす主な原因と、その背後にあるCDIのライフサイクル管理の仕組みを理解できます。さらに、具体的な解決策と、開発中に遭遇しがちなエラーへの対処法を習得し、より堅牢なJakarta EEアプリケーションを開発するための知識が得られます。なぜかうまくいかない@RequestScopedの謎を解き明かし、自信を持って利用できるようになりましょう。

前提知識

この記事を読み進める上で、以下の知識があるとスムーズです。 * Javaの基本的な文法とオブジェクト指向プログラミングの概念 * Jakarta EE (旧Java EE) の基本的な知識（サーブレット、JSFなど） * CDI (Contexts and Dependency Injection) の概念と基本的な使用方法

@RequestScopedとは？そしてなぜRuntime Exceptionが起こるのか？

Jakarta EEにおける@RequestScopedは、CDIが提供するスコープアノテーションの一つであり、HTTPリクエストのライフサイクルにBeanの生存期間を紐付けるために使用されます。具体的には、HTTPリクエストがサーバーに到達した際にBeanのインスタンスが生成され、そのリクエストが処理されてレスポンスが返されるまでの間、同じリクエストスコープ内のすべてのコンポーネントでそのインスタンスが共有されます。そして、リクエストの完了とともにBeanインスタンスは破棄されます。これにより、リクエスト固有の状態を効率的に管理できるため、Webアプリケーション開発において非常に便利な機能です。

しかし、この@RequestScopedを安易に使用するとRuntime Exceptionに遭遇することがあります。その主な理由は、@RequestScoped BeanがCDIコンテナの厳格な管理下でなければ正しく機能しないという点にあります。Runtime Exceptionが発生する典型的なシナリオは以下の通りです。

1. CDIコンテナが起動していない、または無効化されている: CDIは、アプリケーションサーバー（例: WildFly, GlassFish, Open Liberty）によって提供される機能です。beans.xmlという設定ファイルがWebアプリケーションの適切な場所に存在しない場合、CDIコンテナが起動しない、またはそのWebアーカイブ内でCDIが有効にならないことがあります。この状態で@RequestScoped Beanをインジェクションしようとすると、CDIがインスタンスを生成・管理できないためエラーとなります。

2. CDIの管理下にないクラスからインジェクションしようとしている: @RequestScoped Beanを@Injectアノテーションで他のクラスに注入する場合、そのインジェクション元のクラスもまた、CDIコンテナによって管理されている必要があります。例えば、単なるPOJO（Plain Old Java Object）クラスや、CDIが認識しないフレームワークのコンポーネントから@RequestScoped Beanを注入しようとすると、CDIは依存関係を解決できずに例外をスローします。

3. 間違った環境での利用: スタンドアロンのJava SEアプリケーションなど、Webアプリケーションサーバーのコンテキスト外で@RequestScopedを使おうとすると、HTTPリクエストの概念が存在しないため、スコープがアクティブにならずエラーが発生します。この場合、CDI SE (Weld SEなど) を明示的に起動し、リクエストスコープをプログラム的にアクティブにする必要があります。

これらの状況では、主にjakarta.enterprise.context.ContextNotActiveExceptionのような例外や、依存関係解決に関する例外（UnsatisfiedResolutionExceptionなど）が発生し、アプリケーションの起動やリクエスト処理が失敗します。@RequestScopedの利便性を享受するためには、CDIの動作原理と適切な環境設定の理解が不可欠です。

@RequestScopedのRuntime Exceptionを解決する具体的な手順と考慮点

@RequestScopedに関連するRuntime Exceptionを解決するには、CDIコンテナが正しく機能しているか、そしてBeanがCDIのルールに従って利用されているかを確認することが重要です。ここでは具体的な手順と考慮点について解説します。

ステップ1: CDIコンテナが正しく有効化されているか確認する

@RequestScopedのようなCDIスコープは、CDIコンテナがアプリケーション内でアクティブになっている場合にのみ機能します。

• beans.xmlの配置と内容: Jakarta EEのWebアプリケーションでは、WEB-INF/beans.xmlまたはMETA-INF/beans.xmlファイルが存在することで、そのアーカイブ内でCDIが有効になります。このファイルは中身が空でも構いませんが、存在しないとCDIは無効化される場合があります。
  • 例: WEB-INF/beans.xml xml <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="https://jakarta.ee/xml/ns/jakartaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee https://jakarta.ee/xml/ns/jakartaee/beans_3_0.xsd" version="3.0" bean-discovery-mode="annotated"> </beans> bean-discovery-mode="annotated"は、アノテーションが付与されたクラスのみをCDI Beanとして検出するように指定します（CDI 1.1以降の推奨設定）。allにすると全てのクラスをスキャンするため、パフォーマンスに影響が出る可能性があります。
• アプリケーションサーバーの確認: 使用しているアプリケーションサーバー（WildFly, GlassFish, Open Libertyなど）がJakarta EE（またはJava EE）に準拠しており、CDIがデフォルトで有効になっていることを確認してください。もしSpring Bootのようなフレームワークを使用している場合、デフォルトのDIコンテナはSpringのものであるため、CDIを利用するにはWeldなどのCDI実装を追加し、明示的に有効化する設定が必要になります。

ステップ2: @RequestScoped Beanのインジェクション元を確認する

@RequestScoped Beanは、CDIによって管理されている他のBeanからのみ@Injectされるべきです。

• インジェクション元のCDI管理: @RequestScoped Beanを注入しようとしているクラス（例: MyService）自体も、CDIコンテナによって管理されるBeanである必要があります。通常は、@ApplicationScoped, @SessionScoped, @DependentなどのCDIスコープアノテーションや、@Named, @StatelessなどのEJBアノテーションが付与されている必要があります。 ```java // 正しい例: @ApplicationScopedなクラスから@RequestScopedをインジェクション @ApplicationScoped public class MyApplicationService { @Inject private MyRequestBean requestBean; // @RequestScopedなBean

  public String getRequestData() {
      return requestBean.getData();
  }
  

  }

  // @RequestScopedなBeanの定義 @RequestScoped public class MyRequestBean { private String data;

  @PostConstruct
  public void init() {
      this.data = "Data from Request: " + System.currentTimeMillis();
  }
  
  public String getData() {
      return data;
  }
  

  }

  // 間違った例: CDI管理外のPOJOから@RequestScopedをインジェクションしようとする public class StandaloneApp { // @Injectは機能しない！CDIコンテナがこのクラスを管理していないため @Inject private MyRequestBean requestBean;

  public static void main(String[] args) {
      StandaloneApp app = new StandaloneApp();
      // requestBeanはnullまたは初期化されずContextNotActiveExceptionが発生
      // System.out.println(app.requestBean.getData()); 
  }
  

  } ```

ステップ3: プロキシの理解と@RequestScoped Beanの使用方法

CDIでは、ライフサイクルが異なるBean間で依存性注入を行う際に、プロキシが活用されます。

• プロキシの役割: 例えば、ライフサイクルが長い@ApplicationScoped Beanに、ライフサイクルが短い@RequestScoped Beanを注入する場合、CDIは直接インスタンスを注入するのではなく、そのBeanへのプロキシを生成して注入します。このプロキシは、実際にメソッドが呼び出されたタイミングで、現在のリクエストに対応する@RequestScoped Beanのインスタンスを見つけて処理を委譲します。
• シリアライズの問題: @RequestScoped BeanはHTTPリクエスト終了時に破棄されるため、セッションに永続化される@SessionScoped Beanのフィールドとして直接持つと、セッションのシリアライズ時に問題が発生する可能性があります。このような場合は、jakarta.enterprise.inject.Instance<T>を使用して、必要なときにBeanインスタンスをルックアップするように設計を検討してください。 ```java @SessionScoped public class MySessionScopedBean implements Serializable { @Inject private Instance requestBeanInstance; // Instanceでラップ

  public String getRequestDataFromSession() {
      if (requestBeanInstance.isResolvable()) {
          return requestBeanInstance.get().getData(); // 必要なときに取得
      }
      return "No active request context.";
  }
  

  } ```

ステップ4: スタンドアロン環境でのCDI

Webアプリケーションサーバーのコンテキスト外（例: JUnitテスト、シンプルなJavaアプリケーション）でCDIを使用したい場合、Weld SEのようなCDI実装を明示的に起動し、コンテキストをアクティブにする必要があります。

Java

// Weld SEを使ったCDIコンテナの起動例
import jakarta.enterprise.context.RequestScoped;
import jakarta.enterprise.inject.spi.CDI;
import org.jboss.weld.environment.se.Weld;
import org.jboss.weld.environment.se.WeldContainer;

public class StandaloneCdiExample {

    public static void main(String[] args) {
        Weld weld = new Weld();
        WeldContainer container = weld.initialize(); // CDIコンテナを初期化

        try {
            // MyRequestBeanを解決しようとすると、通常はContextNotActiveException
            // MyRequestBean requestBean = container.select(MyRequestBean.class).get(); 

            // リクエストスコープをアクティブにするための特別な処理が必要
            // Weld SEでは、SeContainerInitializerでライフサイクルを管理できますが、
            // RequestScopeをSE環境で明示的にアクティブにするのはより複雑な場合があります。
            // 一般的には、SE環境では@RequestScopedの代わりに@Dependentやカスタムスコープが推奨されます。

            // 例外的な使い方として、テストなどで無理やりコンテキストをアクティブにする
            // これは本番環境のコードでは推奨されません
            container.instance().select(SomeDependentBean.class).get().doSomething();

        } finally {
            container.shutdown(); // コンテナをシャットダウン
        }
    }

    // CDI管理下に置きたいが、直接@RequestScopedではないBean
    // @Dependent (デフォルト) や @ApplicationScoped など
    @ApplicationScoped
    public static class SomeDependentBean {
        @Inject
        private MyRequestBean requestBean; // ここでContextNotActiveExceptionの可能性

        public void doSomething() {
            // 通常、このメソッドがHTTPリクエストのコンテキスト内で呼び出されないと
            // requestBeanはContextNotActiveExceptionを引き起こします
            try {
                System.out.println("Request Bean Data: " + requestBean.getData());
            } catch (jakarta.enterprise.context.ContextNotActiveException e) {
                System.err.println("ContextNotActiveException: " + e.getMessage());
                System.err.println("This is expected in a standalone environment without an active request context.");
            }
        }
    }
}

注意: スタンドアロン環境で@RequestScopedを無理やりアクティブにするのは複雑であり、多くの場合、@Dependentやカスタムスコープ、または別のDIフレームワークの利用を検討すべきです。@RequestScopedはHTTPリクエストに密接に結びついています。

ハマった点やエラー解決

最もよく遭遇するエラーは、やはりjakarta.enterprise.context.ContextNotActiveException: WebBeans context with scope type annotation @RequestScoped is not active for the current threadでしょう。これは文字通り、@RequestScopedが期待するHTTPリクエストコンテキストが、そのコードが実行されているスレッドでアクティブになっていないことを意味します。

• 原因:
  • beans.xmlがない、または誤った場所に配置されている。
  • アプリケーションサーバーがCDIを認識していない（例: WAR/EARデプロイメントに問題がある）。
  • CDIコンテナが管理していないクラスから@RequestScoped Beanにアクセスしようとしている。
  • HTTPリクエスト外（例: @PostConstructメソッド内、バッチ処理、JUnitテスト）で@RequestScoped Beanのメソッドを直接呼び出している。

解決策

1. beans.xmlの確認: 最も基本的なステップです。WEB-INF/beans.xml（Webアプリケーションの場合）またはMETA-INF/beans.xml（JARライブラリやEJBの場合）が存在し、空であっても良いので配置されていることを確認します。
2. インジェクション元の確認: @Injectで@RequestScoped Beanを注入しようとしているクラスが、@ApplicationScoped、@SessionScoped、@Dependent、@StatelessなどのCDI/EJBアノテーションで装飾され、CDIコンテナによって管理されていることを確認します。
3. ライフサイクルとアクセスコンテキストの理解: @RequestScoped Beanは、HTTPリクエストの処理中のみ有効です。アプリケーションの初期化フェーズ（@PostConstructが付与されたメソッド内）や、バックグラウンドスレッド、または通常のJava SEアプリケーションのエントリーポイントから直接アクセスしようとすると、ContextNotActiveExceptionが発生します。
   • 解決策としては、リクエストのライフサイクル内で確実にアクセスされるようにするか、そのような場所では@RequestScopedではない@Dependentや@ApplicationScopedなどのBean、またはInstance<T>を使って遅延解決を検討します。
4. 依存関係の確認: MavenやGradleを使用している場合、jakarta.platform:jakarta.jakartaee-api や CDI実装（例: org.jboss.weld.se:weld-se-core for Weld SE）が正しくプロジェクトの依存関係に追加されているかを確認します。

これらの確認と対処を行うことで、@RequestScopedアノテーション使用時のRuntime Exceptionの多くは解決できるはずです。

まとめ

本記事では、Javaの@RequestScopedアノテーション使用時に発生するRuntime Exceptionの原因とその解決策について詳しく解説しました。

• @RequestScopedはCDIコンテナの管理下で機能する: HTTPリクエストのライフサイクルに紐づくBeanであり、CDIコンテナが正しく初期化・有効化されている環境でなければ機能しません。
• beans.xmlの配置とインジェクション元のCDI管理が重要: CDIコンテナを有効化するためのbeans.xmlの存在と、@RequestScoped Beanを注入する側のクラスもCDI管理下にあることが必須です。
• ContextNotActiveExceptionはCDIコンテキストがアクティブでない証拠: 最も一般的なエラーであり、HTTPリクエストのコンテキスト外でのアクセスや、CDIコンテナの不適切な設定が主な原因です。

この記事を通して、@RequestScopedがRuntime Exceptionを引き起こす仕組みを理解し、その発生原因を特定して適切に対処できるようになることで、読者の皆さんはより堅牢で信頼性の高いJakarta EEアプリケーションを開発できるようになるでしょう。

今後は、@ConversationScopedや@Dependentといった他のCDIスコープの詳細な使い方や、CDIプロキシの内部動作、WeldなどのCDI実装の詳細についても記事にする予定です。

参考資料

• Jakarta EE Platform Specification (CDI)
• Jakarta Contexts and Dependency Injection (CDI) Specification
• Weld - Reference Implementation for CDI
• OpenLiberty: Understanding CDI Scopes