CDIの誤解しがちな仕様とその対処TIPS

日本Jakarta EE & MicroProfile ユーザーグループ第1回勉強会 CDIの誤解しがちな仕様とその対処TIPS アクセンチュア株式会社テクノロジー
コンサルティング本部 ITソリューション FUTOSHI YOSHIZAKI 2026/02/24 © 2026 Accenture All Rights Reserved

© 2026 Accenture All Rights Reserved 2 このセッションについて  足掛け６年に渡り、Java
EE 7のCDIを実案件で使用しておりました。アサイン当初は、 CDIに関する書籍を読んで臨みましたが、実際にやってみると、書籍では書かれていないような出来事や理解の浅かった事がいくつかありました。  当セッションでは、私が実案件の中でつまづいた実例を元に、CDIを扱う上で、書籍等ではあまり強調されていない知見をお話します。  免責事項  当セッションの内容およびデモアプリのソースコードは、私自身の見解を反映しており、必ずしも雇用主の見解を代表するものではありません。

© 2026 Accenture All Rights Reserved 必要な前提知識 このセッションを理解するには、以下の前提知識が必要です。 Jakarta(Java) Contexts
and Dependency Injection Dependency Inject（依存性の注入） AOP（アスペクト指向プログラミング） JavaのGCに関する基礎知識

© 2026 Accenture All Rights Reserved 前提知識を学べる資料 Java EE 7徹底入門
- 翔泳社 https://www.shoeisha.co.jp/book/detail/9784798140926 パーフェクト Java EE - 技術評論社 https://gihyo.jp/book/2016/978-4-7741-8316-9 Jakarta Contexts and Dependency Injection 規格文書 - https://jakarta.ee/specifications/cdi/

© 2026 Accenture All Rights Reserved 目次 1.自己紹介 2. CDIとデモの概要
3. TIPS 4. まとめ

© 2026 Accenture All Rights Reserved 6 自己紹介略歴 2000年に非鉄金属メーカーのユーザー系SIerに新卒入社、主にグループ会社の社内シ
ステム構築に携わる。 2003年に株式会社ソピアにジョインし、2012年に現在の会社に転籍。 多業種にわたり様々な規模のエンタープライズ向けJavaアプリケーションやアーキテクチャの設計・開発に⾧年従事。 近年は、JCLやCOBOL等のメインフレーム資源を、Javaアプリケーションで稼働できるアプリ基盤の設計・開発にいそしむ。 Futoshi Yoshizaki Manager Technology Accenture Japan [email protected]

© 2026 Accenture All Rights Reserved CDIとは何か Java EE 6から導入されたJava
EE版のDI仕様。 Contexts and Dependency Injectionの略 Jakarta EE 9以降の正式名称は、「Jakarta Contexts and Dependency Injection」 Dependency:「再利用されうるオブジェクトや設定情報」。 Injection(注入):「外部代入」 ※意訳 CDIにより提供される主要な機能は次の５つ。 Dependency Injection（依存性の注入） 1 スコープによるBeanインスタンスのライフサイクル管理 2 アスペクト指向プログラミング（AOP/インターセプタ、デコレータ） 3 イベント通知（Observerパターンの実装） 4 EL式との連携 5 • クラスを再利用しやすくなる。 • コードを修正しやすくなる。 • Jakarta EE APサーバーの恩恵（JTAやトランザクションマネージャなど）を享受しやすくなる。 CDIにより得られるメリット

© 2026 Accenture All Rights Reserved CDIを採用する積極的な理由 • 商用Jakarta EE
APサーバー・ベンダーとサブスクリプション契約などを結んでいれば、障害が発生した場合に、調査の依頼ができる。 • 実案件でCDI実装の不具合が判明し、改修に至ったケースは実際にあった。 • 上記契約を結んでいれば、仕様や実装に関する不明点などがある際に、サポート窓口に問い合わせが可能。 • ただし、仕様に対する機能追加などのエンハンスメント・リクエストはなかなか通りにくいことに注意。 • Jakarta EEの実装クラスは、Jakarta EE APサーバー内にパッケージ製品として提供済みであり、その分、warのサイズを節約できる。 • 知名度や普及度の高いフレームワークをメタフレームワークにすることで人材の流動性を高め、開発要員や保守要員を確保しやすくなる。

© 2026 Accenture All Rights Reserved デモの概要実案件で使用していたJEEアプリのランタイムはJavaEE7ということなどもあり、ソースコードは公開不可そこで、当セッションでできるだけ再現性のあるソースコードを提示するために、４つのTIPSごとにデモアプリを実装。
開発ランタイムの仕様は次の通り。 • Java SE 17 • Jakarta EE 10 • Jakarta CDI 4.0.1 • JBoss EAP 8.0.x これから紹介するTIPSの事象を再現するためのソースコードは次のパスで公開している ① TIPS01 https://github.com/jjugnsjeecditips202602/febtips01 ② TIPS02 https://github.com/jjugnsjeecditips202602/febtips02 ③ TIPS03 https://github.com/jjugnsjeecditips202602/febtips03 ④ TIPS04 https://github.com/jjugnsjeecditips202602/febtips04 ビルド・デプロイ手順、動作確認方法は各README.mdを参照の事。 TODO管理から学習作業を行うという疑似業務を行うという想定して、サンプルアプリを実装している。

© 2026 Accenture All Rights Reserved TIPS【1】WELD-000075 DefinitionException トラブル事象次のようなBeanを作成すると、コンパイルエラーは起きないが、
https://github.com/jjugnsjeecditips202602/febtips01/blob/main/src/main/java/io/github/futokiyo/febtips01/service/TodoService.java Webアプリケーションのデプロイ時に、「WELD-000075: Normal scoped managed bean implementation class has a public field」というエラー文言のDefinitionExceptionが発生し、デプロイが失敗する。 ※「WELDって何?」 APPENDIXの豆知識を参照

© 2026 Accenture All Rights Reserved TIPS【1】WELD-000075 DefinitionException 解消方法 JBoss.orgのCDI仕様文書「3.1.
Managed beans」では次のように説明されている。 https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#managed_beans If a managed bean has a non-static public field, it must have scope @Dependent. If a managed bean with a non-static public field declares any scope other than @Dependent, the container automatically detects the problem and treats it as a definition error. 意訳: 管理対象ビーンがpublicのインスタンスフィールドを持つ場合、@Dependentスコープでなければならない。 @Dependentスコープ以外のスコープだと、コンテナが自動的に問題を検出し、定義エラーとして扱う。解消方法としては、次の２つ ①ビーンスコープを@Dependentにする。 ②またはアクセス修飾子をpublicからそれ以外のもの（protectedなど）に変更する。後述するが、安易にDependentスコープに変えないことを推奨。むしろ、アクセス修飾子をpublic以外に変更して問題が無いかを検討するべき。

© 2026 Accenture All Rights Reserved TIPS【1】WELD-000075 DefinitionException 原因 WELD-000075
DefinitionExceptionが発生する条件 1). CDIビーンのスコープが@Dependent以外のもの（≒ノーマルスコープのビーン） 2). publicなインスタンスフィールドが定義されている。このような問題が起きる根本的な原因を理解するには、・クライアントプロキシ（Weld Proxy）・ノーマルスコープと疑似スコープという二つの論点を理解する必要がある。

© 2026 Accenture All Rights Reserved TIPS【1】のデモ実際に、JBoss EAPにWebアプリケーションをデプロイして、 WELD-000075DefinitionException
を起こしてみる。 jjugnsjeecditips202602/febtips01: WELD-000075 DefinitionException を再現続いて、TodoServiceクラスのlearnフィールドの修飾子をpublicからprivateに変えて、デプロイできることを確認する。どうしてこの修正だけで、デプロイが通るようになるのか。これを推察するには、コンテキストとノーマルスコープとクライアントプロキシの理解が必要。

© 2026 Accenture All Rights Reserved クライアントプロキシ詳細な解説は技術評論社「パーフェクト Java
EE」 P63～P74より、一部、引用させていただく。コンテキストとは、各CDI管理Beanが持つスコープ定義に応じて、あるスレッドが置かれた状況を示す。 CDIは、各スコープが意図するコンテキストを考慮して、インスタンスの状態管理を行っている。 CDIでは直接CDI管理Beanのインスタンスをインジェクションせず、「クライアントプロキシ」をインジェクトし、下の図に示すようにプロキシ経由でCDI管理Beanを操作させることで、Bean間の参照の依存を分離している。 @ApplicationScoped @ApplicationScoped @RequestScoped HelloTips01 • learn • todoService TodoService • learn learnのクライアントプロキシ learnのクライアントプロキシ todoServiceのクライアントプロキシ Learn • msg : Would_you_learn_CDI_? Learn • msg : CDIisWeld Httpリクエスト AのLearnインスタンス Httpリクエスト BのLearnインスタンス HTTPリクエストごとに、クライアントプロキシが参照するLearnインスタンスが差し替えられ、サーブレットからは常に正しいインスタンスが参照可能。クライアントプロキシの仕組みにより、異なるライフサイクルを持つインスタンスを独立させている。 Weldにおけるクライアントプロキシ実装のことをWeld Proxyという。

© 2026 Accenture All Rights Reserved ノーマルスコープと疑似スコープの違いノーマルスコープ •前述の通り、コンテキストとクライアントプロキシによってライフサイクルが行われる通常のスコープ
•ノーマルスコープのBean間では、プロキシ経由でアクセスする仕組みにより、循環参照が許容されている。疑似スコープ •厳密にはスコープではなく、疑似スコープ定義のCDI管理Beanはクライアントプロキシを経由せずにアクセスされる。 •疑似スコープのBeanによる循環参照はできない。

© 2026 Accenture All Rights Reserved CDI規格として策定済みのスコープ • アプリケーションのデプロイからアンデプロイされるまで •
ear/warのアプリケーション内で、アプリケーションスコープのインスタンスは共有される • 疑似スコープ。ライフサイクルはインジェクト先のクラスに依存する • bean-discovery-mode:allなどによるBean登録の際、スコープ定義無しのBeanはデフォルトでDependentと判断される • TIPS04で後述するが、動的取得すると、アプリケーションの責務で廃棄の必要性が発生する • 疑似スコープ。アプリケーション中で１つだけインスタンスが生成される • HTTPリクエストからレスポンスまでの間 • サーブレットフィルタ、ServletRequestListener, AsyncListenerの実行中を含む • JAX-RSによるWebサービスの受付から応答までの間 • サーブレットのservice()実行時から、セッションタイムアウト、またはHttpSession.invalidate()によりセッションが破棄されるまで • HTTPセッション間でセッションスコープのインスタンスは共有される • HttpSessionListener, ServletRequestListener, AsyncListenerの実行中を含むインスタンスの生存期間 • リクエストスコープ以上、セッションスコープ未満で任意の⾧さが指定できる • Conversation.begin()からConversation.end()の実行までの間 @ApplicationScoped @Dependent @Singleton @RequestScoped @SessionScoped スコープ @ConversationScoped 1 3 4 5 2 6 技術評論社「パーフェクト Java EE」 P67 表3.2より引用

© 2026 Accenture All Rights Reserved TIPS【1】WELD-000075 DefinitionException 根本的な理由ノーマルスコープのBeanにpublicフィールドを定義すると、クライアントプロキシのフィールドを直接更新
しても、CDI管理Beanインスタンスのフィールドに反映されない。このような誤った使い方を防止するためだと思われる。 learnのクライアントプロキシ Learn •msg : null インジェクション先のインスタンスのメソッド内で、 learn.msg = “aaa”; という代入式を実行しても、クライアントプロキシの参照先のlearn.msgには反映されないちなみに、protectedフィールドとpackage privateフィールドを定義しても、デプロイできる。ただ、カプセル化すれば、このようなことを考える必要はない。 WELD-000075 DefinitionExceptionが発生した際は、スコープをDependentにする前に、本当にpublicフィールドが必要なのかを検討することが望ましい。

© 2026 Accenture All Rights Reserved TIPS【2】同クラス内のメソッドを呼び出すとインターセプターが掛からない事象同じクラスのメソッドを呼ぶような処理がある場合、呼び出し元メソッドと呼び出し先メソッドにAOPのアノテーションを宣言しても、呼び出し先メソッドのインターセプターが実行されない。
具体例 LoggingInterceptor メソッドの開始のログを出力する Logging (アノテーション) （１）インターセプターとアノテーションを用意 Learn メソッド prepare: 学習の準備をするメソッド study: 勉強をする処理当処理で、同じクラス内の preprareを呼び出す。 @Logging @Logging TodoService • learn メソッド doLearn: learn.study();を実行（２）同クラス内のメソッドを呼ぶようなクラスを用意具体的にはstudy()メソッド内で prepare()メソッドを呼び出す。それぞれに@Loggingを宣言（３）インジェクション先の TodoServiceインスタンス内のメソッドで、learn.study()を呼び出す。 Learn.study()の開始ログは出力されるが、 learn.prepare() の開始ログが出力されない。

© 2026 Accenture All Rights Reserved TIPS【2】のデモ次のWebアプリケーションをJBoss EAPにデプロイし、Learn#study()メソッド実行時に、prepareメソッドの開始ログが出力されないことを確認する。
jjugnsjeecditips202602/febtips02: インターセプターの話

© 2026 Accenture All Rights Reserved TIPS【2】同クラス内のメソッドを呼び出すとインターセプターが掛からない原因インターセプターのインスタンスは、プロキシのメソッドにWeaveされているから。実体のLearnインスタンス#study()内でprepare()をコールすると、プロキシのprepareを経由しないため、
prepare()の開始終了ログは出力されない。 TodoService • learn learnのプロキシメソッド study インタセプターメソッド prepare インタセプター Learn メソッド prepare: メソッド study: this.prepare(); @Logging @Logging learn.study() ① ② ③ ④ ⑤ 順を追って説明すると、次の通り ①TodoServiceインスタンス内で、learnのプロキシのstudy()メソッドを実行する。 ②プロキシに織り込まれたLoggingインターセプターの開始ログが出力される。 ③CDI管理Beanのlearn.study()が実行され、 ④studyメソッド内でprepare()メソッドが呼ばれる。 ⑤study()メソッドの処理が終了する。 TodoServiceでlearn(プロキシ)のprepare()を呼ぶと、 Loggingインターセプターによるprepareメソッドの開始ログは出力される。

© 2026 Accenture All Rights Reserved TIPS【2】のようなトラブルを防ぐには AOPのインターセプターのアーキテクチャー原理を正しく理解したうえで、要件定義や設計を行う。付け加えると、Spring Frameworkでもこのような問題は発生する。
気を付けるべきは、「アノテーションをつけただけで、インターセプターが動くようになる」と思わないこと! TIPS【2】のような問題が発生したときに、解決策はないのか。実はある。但し、推奨ではないため、当発表では控えさせていただく。（ヒントは、後述のTIPS【4】）

© 2026 Accenture All Rights Reserved TIPS【3】Javaのクラスが多過ぎるとear/warアプリが起動しなくなる事象ホスト（メインフレーム）・モダナイでは、諸般の事情で、war１つあたりにデプロイされるクラスの数が膨大になることが少なくない。
あるホスト・モダナイ案件では、開発期間中のある時期に、サイズが2.7GBや1.5GBのearファイルをデプロイしようとすると、Webアプリの起動中に大量のメモリを消費しながら、2時間以上かけて、起動が完了するという事象が発生。 ※ジョブスケジューラからのジョブ実行 JOB PARAM定義 XML JP1/AJS3 エージェント DAM部品 DB部品リライトAP (業務プログラム) 元COBOL 元EASY 元ユーティリティ元アセンブラ Shell Script jBatch JSL ジョブ管理サーバ JP1 帳票ユーティリティ商用Java EE AP サーバー某W〇〇 L〇〇〇〇〇〇 NDB DAM 運用管理システム業務プログラム COBOL EASY アセンブラユーティリティ DAM部品 DB部品 ACS コントロール帳票ユーティリティ PRT 帳票 SPOOL ライタ JCL OSⅣ／MSP オペレーティングシステム AIM/JES ※系列間リモートジョブ実行他系列 NJE 2025年以前 2026年以降モダナイゼーションリライトAPのクラスが58万個以上。 earファイルのサイズが1.5～2.7GB

© 2026 Accenture All Rights Reserved TIPS【3】Javaのクラスが多過ぎるとear/warアプリが起動しなくなる原因当事象の原因の一つ: 業務アプリというだけで一律に必要のないものまで、CDI管理Beanにしていた。
beans.xmlがアプリケーション初期化ライフサイクルにどう作用しているのかを知る必要があった。【参考文献】JSR 365: Contexts and Dependency Injection for Java 2.0 > 12. Packaging and deployment https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#packaging_deployment デプロイメント時にCDIコンテナは次のようなフローでロード済みのクラスを読み込み、初期化処理を行う。大量のクラスがBean検出(Bean Discovery)されることが、起動の遅延につながったデプロイメント時におけるCDIコンテナによるアプリケーションの初期化フロー ① 各サービスプロバイダー初期化 ② 検出事前処理 ④ 型検出事後処理 ⑦ デプロイメント問題検出 ⑧ デプロイメント検証事後処理 ⑥ 検出事後処理 ⑨ アプリケーションへのリクエストの送信を開始 ③型検出の実行検出対象のクラスファイルのサイズや数が多くなればなるほど、時間がかかる ⑤ 検出の実行情報の収集／登録クライアントプロキシの設定など ③で検出された型が多ければ多いほど、時間は掛かり、メモリも消費する

© 2026 Accenture All Rights Reserved TIPS【3】Javaのクラスが多過ぎるとear/warアプリが起動しなくなる解決策 beans.xmlのbean-discovery-modeの指定を見直した。 
bean-discovery-mode:allを非推奨または廃止  CDI管理Beanにはスコープのアノテーションを宣言し、クラスライブラリのbean-discovery- mode:annotatedを指定  CDI管理Beanであることが不要なリライトAPクラスのライブラリのbean-discovery-mode:noneを指定 Beanディスカバリモードの振る舞いモード名 • 引数なしコンストラクタを持つすべてのクラスをCDI管理Beanとする。 bean-discovery- mode=“all” • Bean定義アノテーションが付与されているクラスのみ、CDI管理Beanとする。 • beans.xmlを含まない場合(暗黙的Beanアーカイブ)のデフォルト bean-discovery- mode=“annotated” • アーカイブに含むすべてのクラスをCDI管理Beanとして扱わない。CDIによる管理対象外とする。 bean-discovery- mode=“none”

© 2026 Accenture All Rights Reserved TIPS【3】Javaのクラスが多過ぎるとear/warアプリが起動しなくなる解決策 ③型検出の実行 ⑤
検出の実行 CDI管理Beanが不要なBeanアーカイブ bean-discovery-mode=“ none”の beans.xml CDI管理Beanが必要なBeanアーカイブ bean-discovery-mode=“ annotated” のbeans.xml Beanアーカイブ(クラスライブラリのjar)内のMETA-INF/beans.xmlに対し、 bean-discovery-modeをnoneと設定することで、不要なクラスをCDIコンテナが検出しなくなり、起動時間や起動時の消費メモリが改善された

© 2026 Accenture All Rights Reserved TIPS【3】のデモ次のWebアプリケーションのMETA-INF/beans.xmlを確認し、bean-discovery-modeがnoneになっていることを確認。このWebアプリケーションをJBoss
EAPにデプロイし、インジェクションが機能しなくなることを確認。 jjugnsjeecditips202602/febtips03: bean-discovery-mode="none"の動作確認

© 2026 Accenture All Rights Reserved TIPS【4】 Dependentスコープのインスタンスがメモリ解放されない事象 jBatchのジョブやオンライン処理を走らせ続けると、ヒープメモリの使用量が下がらずに上限に近づき続けた。
ヒープダンプを解析したところ、RequestScopedスコープのBeanインスタンスは解放されているにもかかわらず、 DependentスコープのBeanインスタンスが解放されていないことが判明。ネットで検索したところ、同じようなトラブルを見つけた。 https://github.com/quarkusio/quarkus/issues/5209 Issue5209に対する投稿 it's the responsibility of the client to destroy @Dependent instances manually through Instance.destroy() 訳: Dependentスコープのインスタンスを Instance.destroy()で手動で破棄するのは、アプリ側(the client)の責務である。 https://stackoverflow.com/questions/45294758/do-we-need-to- destroy-a-cdi-bean-obtained-programmatically question45294758に対する投稿 you didn't really inject it, instead you did programmatic lookup. Therefore, it isn't bound to any other bean and you should destroy it. 訳: あなたは実際にはDependentのインスタンスをインジェクトせず、代わりにプログラマティックなルックアップを行った。だから、それは他のノーマルスコープのインスタンスに紐づいていないし、あなたはそれを（手動で）破棄すべきだ。

© 2026 Accenture All Rights Reserved TIPS【4】のデモ次のWebアプリをJBoss EAPにデプロイ。 jjugnsjeecditips202602/febtips04:
CDI.current().select(クラスobject).get()という方法で動的に取得したDependentスコープのインスタンスがメモリ解放されない次のURLをブラウザで20回連続で打ち込み、RequestScopedスコープのBeanを動的取得しても OutOfMemoryが起きないことを確認。 http://localhost:8080/febtips04-0.0.1-SNAPSHOT/rest4/rqst 続いて、次のURLを連続で打ち込み、DependentスコープのBeanを動的取得すると、OutOfMemoryが起きることを確認。 http://localhost:8080/febtips04-0.0.1-SNAPSHOT/rest4/dpndnt

© 2026 Accenture All Rights Reserved TIPS【4】 Dependentスコープのインスタンスがメモリ解放されない原因 Dependentのインスタンスを、CDI.current().select(クラスobject).get()という方法で、動的に取
得していたことが大きな原因。 CDIの仕様文書で次のように書かれている。 https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#bm_obtain_instance Instances of dependent scoped beans obtained with this Instance object must be explicitly released by calling Instance.destroy() method. 意訳: javax.enterprise.inject.Instanceオブジェクトにより取得されたDepedentスコープBeanのインスタンスは、javax.enterprise.inject.Instance#destroy()メソッドを呼ぶことにより明示的に解放される必要がある。 TIPS【1】で述べたように、ノーマルスコープのBeanに関しては、コンテキストとクライアントプロキシによりライフサイクル管理されているため、これで取得するのは問題が無い。しかし、DependentスコープのBeanをこの方法で取得した後、個別にCDI.current().destroy()メソッドで、解放処理を行う必要があるということ。

© 2026 Accenture All Rights Reserved CDIの動的取得とは共通部品として、クラス名などのコンポーネントを特定するFQCNを引数にして、それに対応するBeanを取得したいときがある。例）イベント駆動エンジンで、受信するメッセージの種類に応じて、数百から数千のビジネスロジックのCDIビーン
を動的に取得し、実行させたい。 javax.enterprise.inject.InstanceというAPIを使用すると、インジェクションを経由せずに、CDIコンテナに該当Classインスタンスをlookupすることで、そのBeanインスタンスを取得できる。使い方としては次の通り、 ①Java EEサーバーから提供されているCDIコンテナにアクセスできるCDIインスタンスを取得する。 CDI<Object> current = CDI.current(); ② そのCDIインスタンスのselectメソッドに取得したいBeanのクラスオブジェクトを引数として渡し、 javax.enterprise.inject.Instanceを取得する（上記の例では、メッセージの種類に応じたFQCNを登録済にする）。 javax.enterprise.inject.Instance<Sample> instnc = current.select(Sample.class); ③ javax.enterprise.inject.Instanceのget()メソッドを実行し、CDIコンテナからクラス名に該当する Sample sample = instnc.get(); ①～③を縮めて、CDI.current().select(クラス).get()と書くことができる。 ※Spring Frameworkで似たような用途を実現する場合、 ApplicationContextAwareというAPIを使用する。

© 2026 Accenture All Rights Reserved TIPS【4】 WeldのCreationalContextImpl.javaの実装を確認 WeldのCreationalContextImpl.javaのソースコードを確認すると、 https://github.com/weld/core/blob/2.4.8.Final/impl/src/main/java/org/jboss/weld/context/CreationalContextImpl.java
Dependentスコープのインスタンスを格納するためのListオブジェクトフィールドを持ち、 DependentBeanインスタンスをそのListフィールドに追加するメソッドや、解放するメソッドが実装されている。 CDI.current().select().get()を実行すると、 dependentインスタンス格納用Listに生成されたものが格納されている。 CreationalContextImplのdependencesフィールドがDependentスコープインスタンスの ContextualInstanceを参照し続けるため、GCに掛からなくなり、OutOfMemoryが発生する。 CDI.current().destroy()を実行すると、 dependentインスタンス格納用Listの参照から解放されている。

© 2026 Accenture All Rights Reserved Dependentインスタンスはなぜdestroyが必要なの? 申し訳ないが、当方としても、その疑問はまだ解消されていない。ただ、Dependentスコープだから、即、 dependencesに参照され続けるわけではない。このようなコードだとCreationalContextImplに参照され続ける
このようなコードだと org.jboss.weld.contexts.unbound.DependentContextImplの addDependentInstanceメソッドで creationalContext.getDependentInstances().isEmpty()がtrueを返す。即ち、 CreationalContextImpl.dependentInstancesに格納されていないことがわかる。両者の違いはAOPのアノテーション宣言の有無 org.jboss.weld.contexts.unbound.Dep endentContextImplの addDependentInstanceメソッドで Dependentインスタンスが SerializableContextualInstanceImp lにラップされて、dependentInstancesに追加される。

© 2026 Accenture All Rights Reserved Dependentの場合のAOP対応するとWeldSubclassプロキシ化 DependentスコープのBeanにAOPのアノテーションを宣言すると、 CDIコンテナからそれを取得すると、元クラス名$Proxy$_$$_WeldSubclassという名前のプロキシとして、取得またはインジェクションされるようになる。具体例としては、
io.github.futokiyo.febtips04.sample.Sampleならば、 io.github.futokiyo.febtips04.sample.Sample$Proxy$_$$_WeldSubclass これらは、org.jboss.weld.bean.proxy.ProxyObjectの実装で、 weld_setHandler/weld_getHandlerメソッドが拡張されている。

© 2026 Accenture All Rights Reserved TIPS【4】 Dependentスコープのインスタンスがメモリ解放されない解決策動的取得したDependentスコープのBeanを使い終わった後に必ず通る場所で、
CDI.current().destroyに渡す。 TIPS4用HelloTips04#destroyCDIDependentBeanでは念のために org.jboss.weld.bean.proxy.ProxyObject のDependentスコープBeanに絞って、 destroyメソッドに渡すように実装した。 febtips04/src/main/java/io/github/futokiyo/febtips04/rest/HelloTips04.java at main · jjugnsjeecditips202602/febtips04

© 2026 Accenture All Rights Reserved TIPS【4】 Dependentスコープのインスタンスがメモリ解放されない教訓 ①CDIの動的取得(CDI.current().select(クラスobject).get())には、このよう
な副作用があることを認識するべき。 ②理想論かもしれないが、Beanの役割・責務を考慮して、Beanスコープは決めるべき。例）状態を持たないことが確実ー＞ApplicationScoped HttpRequestのライフサイクルならば、RequestScoped HttpSessionのライフサイクルならば、SessionScoped 「よくわからないから、とりあえず、Dependentにしておく」というのは、楽だが、このような副作用をもたらす可能性があることを認識しておくべき。 ③インジェクションで出来ることは、インジェクションで実現する。 ④どうしても、使いたいのであれば、使い終わり次第、確実に CDI.current().destroyで破棄するようにする。

© 2026 Accenture All Rights Reserved 動的取得（CDI.current().select().get()）のメリット／デメリット 1. メリット 1.
インジェクションさせることなく、FQCNの文字列やClassインスタンスにより、CDIのBeanインスタンスを取得できる。 1. アプリ・アーキテクチャ側で、汎用的なBeanインスタンス生成処理を実装するときに便利。 2. デメリット 1. 多用すると、影響範囲が追い辛くなることがある。 2. JUnitで単体テストを実装する場合に、Mockitoでモックを実装する必要がある。 1. モックを実装する工数が発生する。 2. テスタビリティ（テストの容易性）が落ちる。 3. JEE規格上、DependentスコープのBeanを動的取得するの際はCDI.current().destroyメソッドで解放することになっている。何らかの事情でこれが実施されないとメモリリークにつながる。想定されるケース①:最初はRequestスコープで実装し本番稼働を迎えたが、保守の途中で Dependentに変えた際、destroy呼び出しを実装し忘れた。想定されるケース②:例外を投げると、destroyが呼び出されなくなる。

© 2026 Accenture All Rights Reserved まとめ  CDIのインジェクションを使いこなすには、コンテキストとクライアントプロキシの理解が大事。 ※SpringFWでSingletonスコープ・ビーンのフィールドにRequestスコープ・ビーンを定義すると、コンパイルは通るが、
デプロイ時にScopeNotActiveExceptionが発生する。 febtips02springcglib/SingletonがRequestScopeを持つと起きるエラー.txt at main · jjugnsjeecditips202602/febtips02springcglib  CDI Beanのデフォルト・スコープはDependentだが、Spring FWの場合はSingletonスコープ。逆な事に注意  インターセプターの動作原理をある程度理解しておく方が良い。アノテーションを付けるだけで、動くようになるわけではない。  beans.xmlは、Bean検出(Bean Discovery)の制御を担っている。  インジェクションで実現できることはインジェクションを使用する。特に理由もなく動的取得を使っている場合、コード・レビュー時にメモリリークの危険性や脆弱性を指摘し、インジェクションを使用するように修正させる。  動的取得 CDI.current().select(クラス).get()はむやみに使うべきではない。どうしても使用する必要があるならば、DependentスコープのBeanの破棄を確実に漏れなく行うように設計・実装する事。  デフォルトだからという理由で、とりあえずDependentスコープにしない。Beanスコープは何が適切かを要件に応じて、都度、検討することが理想的。  CDI実装であるWeldを意識する方が良い。APIやソースコードの理解が必要になることがある。

© 2026 Accenture All Rights Reserved 豆知識:WELDって何? WeldとはいくつかあるCDI実装の中の一つ。 CDIとは前述の通りJava EE/Jakarta
EE内のDI仕様に過ぎない。 OpenLiberty, WildFlyなど多くのJEEコンテナやAPサーバーで採用されているCDIの実装クラスライブラリ群が「Weld」 https://weld.cdi-spec.org/ CDIには、他に次の実装が存在している。・Quarkus ArC ・ Apache OpenWebBeans ・ Caucho. Resin CanDI ・ Google Guice

CDIの誤解しがちな仕様とその対処TIPS

CDIの誤解しがちな仕様とその対処TIPS

Other Decks in Programming

Featured

Transcript