まず、Spring Boot は規則ベースの自動構成メカニズムを使用します。クラスパスの下で特定の構成ファイルとクラスを検索することにより、アプリケーションで使用される依存関係に基づいて Spring アプリケーションのさまざまなコンポーネントを自動的に構成します。これにより、開発者の作業が大幅に簡素化され、手動構成の必要性が軽減されます。

次に、Spring Boot は条件付き構成メカニズムを使用します。これは、構成の適用が一連の条件が満たされるかどうかに依存することを意味します。条件は、クラスパス内の特定のクラスの存在、特定の Bean の存在など、さまざまな要因に基づくことができます。Spring Boot は、条件付き構成を通じて、さまざまな環境やニーズに応じて動的に構成できます。

Spring Boot の起動構成の原則は次のように要約できます。

起動プロセス中に、Spring Boot は application.properties ファイルや application.yml ファイルなどを含むアプリケーションの構成ファイルをロードして解析します。データベース接続、ログレベルなど、さまざまなプロパティと構成情報をこれらのファイルで定義できます。
Spring Boot はクラスパス内の特定のパッケージを自動的にスキャンして、@SpringBootApplication などの特定のアノテーションを持つクラスを見つけます。このアノテーションは、Spring Boot アプリケーションのエントリポイントを識別します。
Spring Boot は、構成ファイル内のプロパティと条件付き構成メカニズムに基づいて、データベース接続プール、メッセージキュー、Web サーバーなど、アプリケーションのさまざまなコンポーネントを自動的に構成します。カスタム構成が必要な場合は、特別なアノテーションを使用するか、カスタム構成クラスを作成できます。
アプリケーションが起動すると、Spring Boot は Spring コンテナを初期化し、構成に従って対応する初期化作業を実行します。これには、Bean の作成と管理、依存関係注入の処理などが含まれます。

一般に、Spring Boot の起動構成原則は、自動化された規則と条件付き構成メカニズムに基づいています。これにより、アプリケーション構成プロセスが簡素化され、構成ファイルの読み取り、注釈のスキャン、コンポーネントの自動構成などの手順を通じて柔軟性と使いやすさが提供されます。

(2) スタートアップ視点での全体プロセス図の分析

各 SpringBoot プログラムにはメイン入口の main メソッドがあります。SpringApplication.run() が main で呼び出され、SpringBoot プログラム全体が開始されます。このメソッドが配置されているクラスには、次のように @SpringBootApplication のアノテーションを付ける必要があります。

package org.zyf.javabasic;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.EnableAspectJAutoProxy;
import springfox.documentation.swagger2.annotations.EnableSwagger2;

/**
 * 描述：启动入口类
 *
 * @author yanfengzhang
 * @date 2019-12-19 18:11
 */
@SpringBootApplication
@ComponentScan(basePackages = {"org.zyf.javabasic"})
@EnableAspectJAutoProxy(proxyTargetClass = true, exposeProxy = true)
@EnableSwagger2
public class ZYFApplication {
    public static void main(String[] args) {
        ApplicationContext context = SpringApplication.run(ZYFApplication.class, args);
}

その中で、 @SpringBootApplication が展開され、分析されます。

//
// Source code recreated from a .class file by IntelliJ IDEA
// (powered by FernFlower decompiler)
//

package org.springframework.boot.autoconfigure;

import java.lang.annotation.Documented;
import java.lang.annotation.ElementType;
import java.lang.annotation.Inherited;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
import org.springframework.boot.SpringBootConfiguration;
import org.springframework.boot.context.TypeExcludeFilter;
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.FilterType;
import org.springframework.context.annotation.ComponentScan.Filter;
import org.springframework.core.annotation.AliasFor;

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan(
    excludeFilters = {@Filter(
    type = FilterType.CUSTOM,
    classes = {TypeExcludeFilter.class}
), @Filter(
    type = FilterType.CUSTOM,
    classes = {AutoConfigurationExcludeFilter.class}
)}
)
public @interface SpringBootApplication {
    @AliasFor(
        annotation = EnableAutoConfiguration.class
    )
    Class<?>[] exclude() default {};

    @AliasFor(
        annotation = EnableAutoConfiguration.class
    )
    String[] excludeName() default {};

    @AliasFor(
        annotation = ComponentScan.class,
        attribute = "basePackages"
    )
    String[] scanBasePackages() default {};

    @AliasFor(
        annotation = ComponentScan.class,
        attribute = "basePackageClasses"
    )
    Class<?>[] scanBasePackageClasses() default {};
}

@SpringBootApplication には、次の機能を持つ 3 つのアノテーションが含まれています。

@SpringBootConfiguration (内部的には @Configuration): アノテーションが付けられたクラスは、Spring XML 構成ファイル (applicationContext.xml) と同等であり、すべての Bean トランザクションをアセンブルし、Spring コンテキストを提供します。
@ComponentScan: Bean を自動的に検出してアセンブルできるコンポーネントスキャン (@Component や @Configuration など) デフォルトでは、SpringApplication の run メソッド内のクラスが配置されているパッケージパス内のすべてのファイルをスキャンします。
@EnableAutoConfiguration: SpringBoot 自動配線機能をアクティブ化します。

次に、メインエントランスの main メソッドを展開して、全体的なフローチャートを分析します。

2. SpringApplication構築プロセスの分析

main で run メソッドを入力し、SpringApplication インスタンスを作成し、いくつかの基本的な環境変数、リソース、コンストラクター、およびリスナーを構成し、SpringApplication のパラメーター化されたコンストラクターを入力します。

public SpringApplication(ResourceLoader resourceLoader, Class<?>... primarySources) {
        this.sources = new LinkedHashSet();
        this.bannerMode = Mode.CONSOLE;
        this.logStartupInfo = true;
        this.addCommandLineProperties = true;
        this.addConversionService = true;
        this.headless = true;
        this.registerShutdownHook = true;
        this.additionalProfiles = new HashSet();
        this.isCustomEnvironment = false;
        this.resourceLoader = resourceLoader;
        Assert.notNull(primarySources, "PrimarySources must not be null");
        this.primarySources = new LinkedHashSet(Arrays.asList(primarySources));
        this.webApplicationType = WebApplicationType.deduceFromClasspath();
        this.setInitializers(this.getSpringFactoriesInstances(ApplicationContextInitializer.class));
        this.setListeners(this.getSpringFactoriesInstances(ApplicationListener.class));
        this.mainApplicationClass = this.deduceMainApplicationClass();
    }

注: このコンストラクターで行われる作業は、関連するクラス (主にイニシャライザーとリスナー) をコンテナーにロードすることであり、実行されません。

(1) メイン構成クラスが空でないことを確認し、メインクラスを保存します

(2) プロジェクトの種類を推測する

対応するメソッドへの入力の分析は次のとおりです。

推論されるプロジェクトタイプは、リアクティブ、なし、またはサーブレットのいずれかです。デフォルトはサーブレットタイプです。クラスローダーを使用して型を決定するロジックは次のとおりです。

タイプ	状況を判断する
反応的な	Spring WebFluxのDispatcherHandlerは存在しますが、Spring MVCのDispatcherServletは存在しません
なし	どちらも存在しない
サーブレット	残りのすべての状況

(3) 初期化イニシャライザ

まず、ApplicationContextInitializer インターフェイスに入ります。このインターフェイスには、initialize メソッドが 1 つだけあります。

package org.springframework.context;

public interface ApplicationContextInitializer<C extends ConfigurableApplicationContext> {
    void initialize(C var1);
}

分析のためにこのインターフェイスを実装するクラスを表示します。

SharedMetadataReaderFactoryContextInitializer 実装クラスを例として、対応する jar パッケージにジャンプすると、spring.factories がキー ApplicationContextInitializer で対応する実装クラスを指定していることがわかります。次に例を示します。

「SharedMetadataReaderFactoryContextInitializer」を入力します。これは、ApplicationContextInitializer インターフェイスを実装し、内部に初期化メソッドを実装します。

ここで、最初に戻って getSpringFactoriesInstance() メソッドを見てください。このメソッドの中核は、loadFactoryNames() メソッドです。

loadFactoryNames()メソッドに入ると、ApplicationContextInitializerの当該取得内容をファイル「META-INF/spring.factories」から直接取得して保存していることがわかります。

(4) ロード関連リスナー

まず、ApplicationListener インターフェイスに入ります。このインターフェイスには onApplicationEvent メソッドが 1 つだけあります。

package org.springframework.context;

import java.util.EventListener;

@FunctionalInterface
public interface ApplicationListener<E extends ApplicationEvent> extends EventListener {
    void onApplicationEvent(E var1);
}

分析のためにこのインターフェイスを実装するクラスを表示します。

BackgroundPreinitializer 実装クラスを例として、対応する jar パッケージにジャンプします。spring.factories がキー ApplicationListener で対応する実装クラスを指定していることがわかります。

BackgroundPreinitializer を入力します。これは ApplicationListener を実装し、内部で onApplicationEvent を実装します。

以下のような方法:

ここで、最初に戻って getSpringFactoriesInstance() メソッドを見てみましょう。処理フローは上記と同じです。つまり、META-INF/spring.factories に設定されているすべての ApplicationListener がクラスパスから引き続き見つかります。

(5) ApplicationClassメインプログラムの決定

deduceMainApplicationClass メソッドを入力します。

3. SpringApplicationの起動処理の解析

SpringBoot 起動ソリューションには、起動プロセスの監視モジュール、ローディング構成環境モジュール、コア作成コンテキスト環境モジュール、および後続の終了コールバックが含まれています。

(1)モニターはコンテナーの起動を監視し、グラフィカルなページ処理を実行します。

(2) リスナーSpringApplicationRunListeners がリスニングをオンにします

SpringApplicationRunListeners のコレクションが含まれるApringApplicationRunListenersの分析を直接開始します。開始メソッドは、リスナーを走査し、各リスナーの開始メソッドを呼び出すことです。

SpringApplicationRunListener と ApplicationListener はどちらも SpringBoot のイベントリスナーですが、リッスンするイベントとトリガーされるタイミングが異なり、次のような違いがあります。

SpringApplicationRunListener は主に SpringApplication の実行中にアプリケーションの起動、アプリケーションの起動の失敗、アプリケーションの起動の完了などのさまざまなイベントをリッスンします。ApplicationListener は主に、Bean のロード完了、コンテキスト更新完了、その他のイベントなど、Spring コンテナ内のさまざまなイベントをリッスンします。
SpringApplicationRunListenerは、起動タイミングが異なりますが
、SpringApplicationの起動と同時に動作を開始し、アプリケーションの起動、アプリケーションの起動失敗、アプリケーションの起動成功などの各種イベントを受け取ることができます。ApplicationListener は Spring コンテナが開始された後にのみ動作を開始でき、Spring コンテナ内のさまざまなイベントをリッスンします。
さまざまな使用シナリオ
実際のアプリケーションでは、SpringApplicationRunListener は主に、アプリケーションの起動前後に特定の操作を実行する、アプリケーションの起動失敗イベントをリッスンして対応する操作を実行するなど、SpringApplication の起動プロセスを監視するために使用されます。ApplicationListener は、Bean のロード後の対応する操作の実行、コンテキストの更新完了後のステータスの更新など、Spring コンテナ内のさまざまなイベントをリッスンするために使用されます。

つまり、SpringApplicationRunListener と ApplicationListener はどちらも SpringBoot のイベントリスナーですが、リッスンするイベント、トリガーのタイミング、使用シナリオなどが異なるため、アプリケーションの特定のニーズに基づいてアプリケーションを完成させるために適切なリスナーを選択する必要があります。取り扱い。

入力する前に SpringApplicationRunListener クラスを見てください。

package org.springframework.boot;

import org.springframework.context.ConfigurableApplicationContext;
import org.springframework.core.env.ConfigurableEnvironment;

public interface SpringApplicationRunListener {
    void starting();

    void environmentPrepared(ConfigurableEnvironment environment);

    void contextPrepared(ConfigurableApplicationContext context);

    void contextLoaded(ConfigurableApplicationContext context);

    void started(ConfigurableApplicationContext context);

    void running(ConfigurableApplicationContext context);

    void failed(ConfigurableApplicationContext context, Throwable exception);
}

対応する方法は次のように説明されます

リスニング方法	動作フェーズの説明	SpringBootの開始バージョン
contextLoaded(構成アプリケーション環境)	ConfigurableApplicationContext は読み込みを完了しましたが、まだ開始されていません。ApplicationContext が IoC 構成を完了したことをリスナーに通知します	1.0
contextPrepared(構成アプリケーション環境)	ConfigurableApplicationContext の準備が完了しました: ApplicationContext が作成され、初期化されたことをリスナーに通知します。	1.0
環境準備済み(構成環境)	ConfigurationEnvironmentを調整できるようになりました	1.0
失敗しました(構成アプリケーション環境、スロー可能)	Spring アプリケーションの実行に失敗しました	2.0
実行中(構成アプリケーション環境)	Springアプリケーションが実行中です	2.0
開始されました(構成アプリケーション環境)	ConfigurableApplicationContext が開始され、SpringBean が初期化されました。	2.0
起動（）	run メソッドが実行されるとすぐに実行します。リスナーに通知し、SpringBoot が実行を開始します。	1.0

通常、アプリケーションのリスナー SpringApplicationRunListeners を作成し、start() を呼び出して listen を開始します。まず、getRunListeners ですべてのリスナーを取得し、開始をオンにします。

(3)environmentPrepared環境準備処理

このコードを分析し、prepareEnvironment メソッドを入力して環境を準備すると、次のことがわかります。

まず、環境 ConfigurationEnvironment を作成します (存在する場合は取得し、存在しない場合は作成します)。

このメソッドによって返された場所に戻り、this.configureEnvironment を通じて環境を設定し、その後に次のようにします。

環境が構成された後、SpringApplicationRunListener のenvironmentPrepared 関数がコールバックされ、次のメソッドに入ります。

environmentPrepared環境の準備中にリスナーに通知され、環境の準備が完了していることがわかります。

最初に戻ると、環境の準備が完了すると、bindToSpringApplication を通じて環境がプログラムにバインドされていることがわかります。

(4)バナー印刷

対応するバナー情報を印刷します

つまり、以下に示すように、起動後に変更された部分です

実際には、画像を変更することで画像を置き換えることができ、たとえば次のように、banner.txt 情報をリソースに追加するだけで済みます。

原則に対応するコード分析をクリックし続けると、置き換えのアイデアがこのフォローアップで説明されます。

(5) Springアプリケーションコンテキストの作成

アプリケーションコンテキストの作成は IOC プロセスです。IOC コンテナは、SpringBoot アプリケーションコンポーネント全体を駆動するコアです。次のメソッドを入力します。

ここでの作成は、構築フェーズ中に SpringApplication によって推論された Web アプリケーションのタイプに基づいて IOC コンテナを作成することであり、IOC コンテナは実行によって返されるコンテンツです。

(6) Springアプリケーションコンテキスト準備フェーズ

prepareContext メソッドは、リスナー、環境、applicationArguments、バナーなどの重要なコンポーネントをコンテキストオブジェクトに関連付け、コンテキストオブジェクトをさらに構成して、このメソッドの詳細な分析を開始します。

最初に生成された環境と ApplicationContext がそれぞれ保存されていることがわかります。次の applyInitializers メソッドで初期化を実行し、このメソッドに入ります。

このメソッドは内部的にすべての初期化子を走査し、すべての初期化メソッドを順番にコールバックします (これらの初期化子は、新しい springApplication を構築するときに springboot が最初に開始されたときに追加されました)。現在の環境を設定し、初期化を完了した後、すべての Linsteners の contextPrepared メソッドがコールバックされます。。

次に、次のようにコマンドラインパラメータとバナーを IOC コンテナに登録します。

すべての操作が完了すると、このメソッドは上記のように、Listeners の contextLoaded メソッドをコールバックします。

(7) Springアプリケーションコンテキストリフレッシュフェーズ

このメソッドでは、SpringBean 破棄ライフサイクルコールバックを実装するために shutdownHook スレッドが最初に登録されます。

更新を実行した後のコンソールでは、Tomcat の Bean といくつかの IOC コンテナがロードされていることがわかります。

(8) Springアプリケーションコンテキスト終了段階

afrerRefresh() にはコンテンツ処理はなく、メソッドは後続のバージョンでも変更されません。

protected void afterRefresh(ConfigurableApplicationContext context,
 ApplicationArguments args) {
    }

終了タイマーが停止し、リスナーのstarted()が呼び出されます。

(9)コールバックワーク処理

メソッド分析を入力します

ApplicationContext は IOC コンテナです。このメソッドは、IOC コンテナからすべてのApplicationRunner と ConmmandLineRunnerを取得し、トラバースしてコールバックします。

callRunners で使用される 2 つのクラスはほぼ同等です。どちらも顧客定義の作業を行うために使用され、ユーザー定義の実装クラスの run メソッドは、プロセス全体が完了した後にのみ呼び出されます。2 つの run メソッド実装メソッド基本的にコンテナが初期化されるときにすべて呼び出されます。

その直後、例外がない場合、コードは次のように実行されます。

リスナーコールバックの running() メソッドは、SpringApplication の通常の開始と終了を表します。

(10) SpringApplication 起動例外処理

例外の主な理由は例外の処理にあるため、このメソッドの分析に入ってみましょう。

この例外レポートクラスはカスタマイズと自動構成もサポートしていることがわかります。構成が完了すると、Springboot は基本的な仕上げ作業を実行し、アプリケーション環境コンテキスト (IOC コンテナー) を返します。

4. SpringBoot自動構成解析

Spring Boot の自動構成モジュールはフレームワークの中核機能の 1 つであり、アプリケーションの構成作業を大幅に簡素化できます。以下は、Spring Boot 自動構成モジュールの説明と分析です。

自動構成の原則: Spring Boot の自動構成モジュールは、構成よりも規約の原則に基づいています。クラスパスをスキャンして依存関係と構成を確認することにより、アプリケーションのさまざまなコンポーネントを自動的に構成します。条件付き構成メカニズムを使用して、環境と条件に基づいて適切な構成を自動的に選択します。
自動構成の実装: Spring Boot 自動構成モジュールは@Conditional アノテーションと条件付きアノテーションを使用して条件付き構成を実装します。これらのアノテーションは、一連の条件に基づいて構成を有効にするかどうかを決定できます。たとえば、@ConditionalOnClass は、指定されたクラスがクラスパスに存在するかどうかに基づいて、構成が有効かどうかを判断します。
自動構成のロード順序: Spring Boot の自動構成は、クラスパスの下の META-INF/spring.factories ファイルで定義された自動構成クラスを通じて実装されます。これらの自動構成クラスは、条件に基づいて自動的にロードおよび初期化され、構成されます。条件に応じて複数の自動設定クラスをロードすることができ、優先順位に従って設定されます。
自動構成のカスタマイズ: Spring Boot 開発者は自動構成をカスタマイズできます。@Conditional アノテーションと条件付きアノテーションを使用して、自動構成の動作に影響を与えるカスタム条件を定義できます。@EnableAutoConfiguration アノテーションを使用して、自動構成の有効化または無効化を制御することもできます。
自動構成の利点: Spring Boot の自動構成モジュールは多くの利点をもたらします。手動設定の手間が大幅に軽減され、開発効率が向上します。これにより、賢明なデフォルト構成が提供され、構成ミスのリスクが軽減されます。同時に、その条件付き構成メカニズムによりアプリケーションがより柔軟になり、さまざまな環境やニーズに応じて動的に構成できます。

全体として、Spring Boot の自動構成モジュールはフレームワークの重要な機能の 1 つです。設定に対する規約の原則と条件付き設定メカニズムを通じて、アプリケーションのさまざまなコンポーネントの自動ロードと設定を実現します。これにより、開発者に利便性と柔軟性が提供され、アプリケーションの構成プロセスが大幅に簡素化されます。

最初のダイアグラム分析に戻りますが、構成モジュールは主に SpringFactoriesLoader ( Spring ファクトリローダー)を使用します。このオブジェクトは、loadFactoryNames メソッドを提供し、入力パラメータは、factoryClass と classLoader (つまり、ファクトリクラス名と対応する Class)です。メソッドは、指定された classLoader に従って、クラスローダーの検索パスの下に指定されたファイル、つまり spring.factories ファイルをロードします。受信ファクトリクラスはインターフェイスです。これらの実装クラスのクラス名を取得した後、 loadFactoryNames メソッドはクラス名のコレクションを返します。メソッド呼び出し元がこれらのコレクションを取得した後、リフレクションを通じてクラスオブジェクトとこれらのクラスのコンストラクターを取得し、最後にインスタンスを生成します。

(1)自動組立原理の解析

@SpringBootApplication の @EnableAutoConfiguration アノテーションから、自動構成インポートセレクター AutoConfigurationImportSelect がインポートされていることがわかります。

package org.springframework.boot.autoconfigure;

import java.lang.annotation.Documented;
import java.lang.annotation.ElementType;
import java.lang.annotation.Inherited;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
import org.springframework.context.annotation.Import;

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@AutoConfigurationPackage
@Import({AutoConfigurationImportSelector.class})
public @interface EnableAutoConfiguration {
    String ENABLED_OVERRIDE_PROPERTY = "spring.boot.enableautoconfiguration";

    Class<?>[] exclude() default {};

    String[] excludeName() default {};
}

そのクラス図は次のとおりです

最終的に ImportSelector (セレクター) と BeanClassLoaderAware (Bean クラスローダーミドルウェア) を実装していることがわかります。このセレクターの機能はコンポーネントをインポートすることです。

すべての自動アセンブリロジックは、AutoConfigurationImportSelector の selectImports メソッドに実装されます。

getAutoConfigurationEntry() メソッドを入力します。

getCandidateConfigurations() を入力して候補構成メソッドを取得すると、コア SpringFactoriesLoader のloadFactoryNames() メソッドが表示されます。

このうち、SpringFactoriesLoader は Spring Framework ファクトリ機構のローダーであり、loadFactoryNames はそれに対応するロードメソッドです。

ここでのロード原理は次のとおりです。

すべての jar パッケージパスの下の META-INF/spring.factories をスキャンします。ここでは、対応する URL パスがクラスローダーを通じて生成されます。
スキャンされたコンテンツをプロパティオブジェクトにパックし、このオブジェクトのコンテンツを走査して、マップを返します。マップのキーはインターフェイスの完全なクラス名で、値はインターフェイスのすべての実装クラスのリストです (リスト内の要素はロードの繰り返しを防ぐために重複が排除されます)、この値の情報は後でloadSpringFactoriesメソッドの戻り値として使用されます。
前のステップで返されたマップ内の指定されたクラス名マッピングの実装クラスの完全なクラス名のリストを検索して返します。

getCandidateConfiguration メソッドの getSpringFactoriesLoaderFactoryClass メソッドを見てください。返されるのは EnableAutoConfiguration クラスです。

つまり、先ほどのプロパティからこのクラスに対応する値を取得してコンテナに追加する必要があります。

mybatis-spring-boot-autoconfigure の下にある spring.factories ファイルを選択し、分析します。

各 xxxAutoConfiguration クラスはコンテナ内のコンポーネントであり、自動構成に使用するためにコンテナに追加されます。

コンテナに入ったときにのみ、これらの自動構成クラスが有効になり、自動構成機能が実行されます。

(2) 条件付き自動組み立て

@Configuration を使用する自動構成クラスの場合、条件付き自動アセンブリは @condition をコアとして使用します。スプリングの最下層の @conditional アノテーションは、さまざまな条件に基づいて構成クラス全体の構成に対して有効になります。

条件付きアセンブリは次のカテゴリに分類できます。

クラスの条件付きアノテーション

注釈	説明する
@ConditionalOnClass	指定したクラスが存在する場合に有効になります。
@ConditionalOnMissingClass	指定されたクラスが欠落している場合に有効になります。

Bean 条件アノテーション

注釈	説明する
@ConditionalOnBean	指定されたBeanが存在する場合に有効になります。
@ConditionalOnMissingBean	指定された Bean が欠落している場合に有効になります。

属性条件の注釈

注釈	説明する
@ConditionalOnProperty	プロパティ (application.properties) の値を使用して、有効かどうかを判断します。

Webアプリケーション条件アノテーション

注釈	説明する
@ConditionalOnWebApplication	Web タイプの場合に有効になります
@ConditionalOnNotWebApplication	Web タイプではない場合に有効になります。

その他の条件付きメモ

@条件付き拡張アノテーション	機能 (現在指定されている条件が満たされているかどうかを判断します)
@ConditionalOnJava	システムの Java バージョンは要件を満たしていますか?
@ConditionalOnExpression	SpEL 式の仕様を満たしています
@ConditionalOnSingleCandidate	コンテナ内に指定された Bean が 1 つだけ存在するか、この Bean が優先 Bean です
@ConditionalOnResource	指定されたリソースファイルがクラスパスに存在するかどうか
@conditionalon	指定された項目はJNDIに存在します

@ConditionalOnWebApplication を分析しています

package org.springframework.boot.autoconfigure.condition;

import java.lang.annotation.Documented;
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
import org.springframework.context.annotation.Conditional;

@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Conditional({OnWebApplicationCondition.class})
public @interface ConditionalOnWebApplication {
    ConditionalOnWebApplication.Type type() default ConditionalOnWebApplication.Type.ANY;

    public static enum Type {
        ANY,
        SERVLET,
        REACTIVE;

        private Type() {
        }
    }
}

OnWebApplicationCondition クラスを入力します。このクラスには getMatchOutcome() メソッドがあり、現在の構成条件を満たしているかどうかを判断します。

このメソッドは、最初にこのアノテーションが使用されているかどうかを判断し、次に isWebApplication を使用して Web アプリケーションであるかどうかを判断します。これらの match メソッドは、指定された条件が true であるかどうかを判断し、コンポーネントがコンテナに追加され、構成コンテンツが有効になります。。

(3) 自動設定原理の例：HttpEncodingAutoConfiguration（HTTPエンコーディング自動設定）

次の情報が表示されます。

@Configuration は、これが、記述された構成ファイルと同様の構成クラスであることを意味し、コンテナーにコンポーネントを追加することもできます。
@EnableConfigurationProperties は、指定されたクラスの ConfigurationProperties 関数を有効にし、構成ファイル application.properties の値を ServerProperties にバインドし、ServerProperties を IOC コンテナに追加します。
@ConditionalOnClass は、現在のプロジェクトにこのクラスが含まれているかどうかを判断するために使用されます。ここでの CharacterEncodingFilter の役割は、springMVC の文字化け解決用のフィルターです (Spring の xml ファイルで事前に構成されています)。このフィルターがあれば、構成が有効になります。
@ConditionalOnProperty は、この構成が存在するかどうかを決定します。matchIfMissing = true は、このプロパティが構成ファイルに存在しない場合でも、デフォルトで有効になることを意味します。

spring.factories のすべての自動構成クラスが有効であるわけではなく、それぞれに独自の有効条件があることに注意してください。現在のさまざまな条件に基づいて、この構成クラスが有効になるかどうかを決定します。構成クラスが有効になると、この構成クラスはさまざまなコンポーネントをコンテナに追加します。これらのコンポーネントのプロパティは、対応するプロパティから取得されます。これらのクラスの各プロパティは、構成ファイルにバインドされています。

SpringBoot 起動構成原則の分析

1. 全体概要

(1) 基本的な全体予備分析