対象ファイル

src/main/java/com/example/demo/BootBasicApplication.java

はじめに

boot_basic プロジェクトの核心部分であるメイン実行クラス BootBasicApplication.java の解析を行いました。

Spring Boot アプリケーションが起動する際、内部でどのように IoC コンテナが生成され、内蔵 Tomcat が立ち上がるのか、その一連の処理フローとアノテーションの働きを整理してみました。

処理フローと構成要素の確認

このクラスは Spring Boot のエントリーポイント（Entry Point）として機能しており、大きく分けて以下のような流れで処理が進みます。

JVM起動 (Java Main Method Execution)
main メソッドが呼び出されてアプリケーションが始動。
SpringApplication.run() の実行
メインクラスの情報と引数を渡し、起動ロジックを開始。
Spring IoC コンテナ (ApplicationContext) の生成
Bean のライフサイクルを管理するコンテナを初期化。
コンポーネントスキャン (Component Scan)
自身のパッケージ配下を探査し、@Controller や @Service などを Bean として自動登録。
自動設定および内蔵サーバーの起動
依存関係（build.gradle など）に基づいて必要な設定を自動適用し、内蔵 Tomcat を起動。

気になった部分・改善ポイント

コードを読んでいて特に気になったのは、コンポーネントスキャン（Component Scan）の有効範囲と実行可能 JAR（Executable JAR）の構成です。

1. パッケージ位置によるコンポーネントスキャン制限

@SpringBootApplication は、自身が配置されているパッケージ（今回で言えば com.example.demo）とその配下のみをデフォルトのスキャン対象とします。

もし外部パッケージのクラスを Bean 登録したい場合は、以下のように @ComponentScan で明示的に basePackages を指定して拡張してあげる必要があります。

@SpringBootApplication
@ComponentScan(basePackages = "com.example")
public class BootBasicApplication {
public static void main(String[] args) {
SpringApplication.run(BootBasicApplication.class, args);
}
}

「クラスを作ったのに Bean 登録されない」というトラブルは、初心者だとこのパッケージ位置のズレが原因になることが多いので注意したいポイントです。

2. 実行可能 JAR ビルド時のメインクラス固定

スタンドアロンで動く Executable JAR をビルドする際、この BootBasicApplication クラスが MANIFEST ファイルの Main-Class として自動指定されます。外部の WAS を用意しなくても java -jar 一発でサーバーが起きる裏には、この仕組みがしっかり働いているんだなと改めて実感しました。

今回学んだこと

たった数行のシンプルなクラスですが、@SpringBootApplication の裏側で「設定の自動適用」「コンポーネントスキャン」「内蔵 Tomcat の起動」がすべて一括で処理されていることがコードを通して理解できました。

次回は HTTP リクエストを受け取って JSP 画面にマッピングする TestController.java の解析に進みたいと思います！