SpringbootでDIされる項目がnullの時の原因特定方法

Question

Springbootを使用して業務アプリケーション開発をしています。
DIという考え方に慣れておりません。

@Autowiredアノテーションを使用してDI(依存性の注入)を行うコードがあったとします。
このとき、設定ファイルが正常に記載されていないなどの理由でDIが正常に行われず、
@Autowiredアノテーションを付与したインスタンス変数がnullのまま、
DIによるインスタンス化がされないことがあります。

この時に「DIが失敗したんだな」ということは理解できるんですが、
何を原因として失敗したかを知る術は無いものか、ということが質問の趣旨となります。
実行時にNullPointerExceptionが出るだけで何が悪いのかがわからず、
原因究明に時間が掛かっており何かいい手はないものかと探していますが見つけきれていません。

また、前述の通り八方塞になった場合にDIによってインスタンス化せず、フレームワークの
DI向けに作られたクラスであってもJavaコード上で通常通りnewでインスタンス化して
ゴテゴテとコーディングすることについての賛否やご意見なども伺えると嬉しいです。

Answer 1

NullPointerしか出てこないとありますが、スタックトレースを読む癖はつけていますか？
Springのエラーメッセージはかなり親切ですよ。DI失敗関連のエラーでは大抵の場合、併発してBeanCreationExceptionが発生し、そこに原因が書いているはずです。

DIに失敗するパターンとしては以下のようなものが挙げられます。
①Autowiredアノテーションのつけ忘れ
[発生する例外]NullPointerExceptionが単独で発生し、BeanCreationExceptionが同時に発生しない
[対処]@Autowiredをつける。

②変数にインジェクションできるインスタンスがDIコンポーネントに存在しない
[発生する例外]NullPointerExceptionの上にBeanCreationExceptionが発生
[対処]大抵はインジェクションする側に@Componentのつけ忘れ

③変数にインジェクションできるインスタンスが2つ以上DIコンポーネントにある
[発生する例外]NullPointerExceptionの上にBeanCreationExceptionが発生
[対処]インジェクション先の変数に対して、インジェクションできるインスタンスが2個以上ある。
＠Primaryをつけるなどしてインスタンスごとの優先順位をつける。

また、DIを前提としているところでnewでインスタンスを作成してもよいのか、という点ですが、
①テストしない
②納品後のメンテナンスや機能追加など知ったことではない
という条件が揃えばnewしても問題ないと思います。そんなプロダクトはめったに無いですし、私がそんなプロダクトの保守を任されたらその日のうちに退職届を提出すると思いますが。。。

設定ファイル周りの取り回しが難しいのであれば、チームのエキスパート開発者に設定ファイル管理を一任してしまい、「エキスパート開発者以外は設定ファイルを触ってはならない。一般開発者はアプリケーションコード内での＠Autowiredによる呼び出しのみ可能」という開発フローを採用するのも手段の一つです。

Answer 2

"DIコンテナにインスタンスの生成やライフサイクルを任せる規約を利用する"の面で、DIコンテナを使う意味があるのではないかと個人的には思います。

特に規約に縛られることなくインスタンスを作りたいのであればDIコンテナを使う理由はなくなってしまいます。
Springであればアスペクトの注入も可能ですので、インスタンスの実行前処理・後処理もSpringに任せるといったこともできますね。