このセクションでは、Spring Boot の使用方法について詳しく説明します。ビルドシステム、自動構成、アプリケーションの実行方法などのトピックを扱います。また、Spring Boot のベストプラクティスもいくつか取り上げています。Spring Boot に関して特別なことは何もありませんが(それは使用する単なるライブラリにすぎません)、従えば、開発プロセスを少し簡単にするいくつかの推奨事項があります。

Spring Boot を使用する場合は、このセクションに進む前に入門ガイドを参照してください。

1. ビルドシステム

依存関係管理をサポートし、「Maven セントラル」リポジトリに公開されたアーティファクトを消費できるビルドシステムを選択することを強くお勧めします。Maven または Gradle を選択することをお勧めします。Spring Boot を他のビルドシステム(Ant など)で動作させることは可能ですが、それらは特に十分にサポートされていません。

1.1. 依存関係管理

Spring Boot の各リリースは、サポートしている依存関係のリストを提供しています。Spring Boot が管理しているため、実際には、ビルド設定でこれらの依存関係のバージョンを指定する必要はありません。Spring Boot 自体をアップグレードすると、これらの依存関係も一貫した方法でアップグレードされます。

バージョンを指定して、必要に応じて Spring Boot の推奨を上書きすることもできます。

厳選されたリストには、Spring Boot で使用できるすべての Spring モジュールと、サードパーティライブラリの洗練されたリストが含まれています。このリストは、MavenGradle の両方で使用できる標準の部品表(spring-boot-dependencies)として入手できます。

Spring Boot の各リリースは、Spring Framework の基本バージョンに関連付けられています。バージョンを指定しないことを強くお勧めします。

1.2. Maven

Spring Boot を Maven で使用する方法については、Spring Boot の Maven プラグインのドキュメントを参照してください。

1.3. Gradle

Spring Boot を Gradle で使用する方法については、Spring Boot の Gradle プラグインのドキュメントを参照してください。

1.4. Ant

Apache Ant + Ivy を使用して Spring Boot プロジェクトを構築することができます。spring-boot-antlib “ AntLib ”モジュールは、Ant が実行可能な jar を作成するのを支援するためにも利用可能です。

依存関係を宣言するための一般的な ivy.xml ファイルは、次の例のようになります。

<ivy-module version="2.0">
    <info organisation="org.springframework.boot" module="spring-boot-sample-ant" />
    <configurations>
        <conf name="compile" description="everything needed to compile this module" />
        <conf name="runtime" extends="compile" description="everything needed to run this module" />
    </configurations>
    <dependencies>
        <dependency org="org.springframework.boot" name="spring-boot-starter"
            rev="${spring-boot.version}" conf="compile" />
    </dependencies>
</ivy-module>

典型的な build.xml は、次の例のようになります。

<project
    xmlns:ivy="antlib:org.apache.ivy.ant"
    xmlns:spring-boot="antlib:org.springframework.boot.ant"
    name="myapp" default="build">

    <property name="spring-boot.version" value="2.3.1.RELEASE" />

    <target name="resolve" description="--> retrieve dependencies with ivy">
        <ivy:retrieve pattern="lib/[conf]/[artifact]-[type]-[revision].[ext]" />
    </target>

    <target name="classpaths" depends="resolve">
        <path id="compile.classpath">
            <fileset dir="lib/compile" includes="*.jar" />
        </path>
    </target>

    <target name="init" depends="classpaths">
        <mkdir dir="build/classes" />
    </target>

    <target name="compile" depends="init" description="compile">
        <javac srcdir="src/main/java" destdir="build/classes" classpathref="compile.classpath" />
    </target>

    <target name="build" depends="compile">
        <spring-boot:exejar destfile="build/myapp.jar" classes="build/classes">
            <spring-boot:lib>
                <fileset dir="lib/runtime" />
            </spring-boot:lib>
        </spring-boot:exejar>
    </target>
</project>
spring-boot-antlib モジュールを使用したくない場合は、howto.html 「使い方」を参照してください。

1.5. スターター

スターターは、アプリケーションに含めることができる便利な依存関係記述子のセットです。必要なすべての Spring および関連テクノロジーのワンストップショップを利用して、サンプルコードを探したり、依存関係記述子のコピーアンドペーストを行う必要はありません。例:データベースアクセスに Spring と JPA の使用を開始する場合は、プロジェクトに spring-boot-starter-data-jpa 依存関係を含めます。

スターターには、プロジェクトを迅速に立ち上げて実行するために必要な多くの依存関係と、管理された推移的な依存関係のサポートされたセットが含まれています。

名前の内容

すべての公式スターターは、同様の命名パターンに従います。spring-boot-starter-*、ここで * は特定のタイプのアプリケーションです。この命名構造は、スターターを見つける必要がある場合に役立つことを目的としています。多くの IDE の Maven 統合により、名前で依存関係を検索できます。例:適切な Eclipse または STS プラグインがインストールされている場合、POM エディターで ctrl-space を押し、「spring-boot-starter」と入力して完全なリストを表示できます。

独自のスターターを作成する」セクションで説明したように、サードパーティのスターターは公式の Spring Boot アーティファクト用に予約されているため、spring-boot で開始しないでください。むしろ、サードパーティのスターターは通常、プロジェクトの名前で始まります。例: thirdpartyproject というサードパーティのスタータープロジェクトは、通常 thirdpartyproject-spring-boot-starter という名前になります。

次のアプリケーションスターターは、org.springframework.boot グループで Spring Boot によって提供されます。

表 1: Spring Boot アプリケーションスターター
名前 説明

spring-boot-starter

自動構成サポート、ロギング、YAML を含むコアスターター

spring-boot-starter-activemq

Apache ActiveMQ を使用した JMS メッセージングのスターター

spring-boot-starter-amqp

Spring AMQP および Rabbit MQ を使用するためのスターター

spring-boot-starter-aop

Spring AOP および AspectJ を使用したアスペクト指向プログラミングのスターター

spring-boot-starter-artemis

Apache Artemis を使用した JMS メッセージングのスターター

spring-boot-starter-batch

Spring Batch を使用するためのスターター

spring-boot-starter-cache

Spring Framework のキャッシュサポートを使用するためのスターター

spring-boot-starter-data-cassandra

Cassandra 分散データベースおよび Spring Data Cassandra を使用するためのスターター

spring-boot-starter-data-cassandra-reactive

Cassandra 分散データベースおよび Spring Data Cassandra Reactive を使用するためのスターター

spring-boot-starter-data-couchbase

Couchbase ドキュメント指向データベースおよび Spring Data Couchbase を使用するためのスターター

spring-boot-starter-data-couchbase-reactive

Couchbase ドキュメント指向データベースおよび Spring Data Couchbase Reactive を使用するためのスターター

spring-boot-starter-data-elasticsearch

Elasticsearch 検索および分析エンジンと Spring Data Elasticsearch を使用するためのスターター

spring-boot-starter-data-jdbc

Spring Data JDBC を使用するためのスターター

spring-boot-starter-data-jpa

Hibernate で Spring Data JPA を使用するためのスターター

spring-boot-starter-data-ldap

Spring Data LDAP を使用するためのスターター

spring-boot-starter-data-mongodb

MongoDB ドキュメント指向データベースと Spring Data MongoDB を使用するためのスターター

spring-boot-starter-data-mongodb-reactive

MongoDB ドキュメント指向データベースと Spring Data MongoDB Reactive を使用するためのスターター

spring-boot-starter-data-neo4j

Neo4j グラフデータベースと Spring Data Neo4j を使用するためのスターター

spring-boot-starter-data-r2dbc

Spring Data R2DBC を使用するためのスターター

spring-boot-starter-data-redis

Spring Data Redis および Lettuce クライアントで Redis Key-Value データストアを使用するためのスターター

spring-boot-starter-data-redis-reactive

Spring Data Redis リアクティブおよび Lettuce クライアントで Redis キー値データストアを使用するためのスターター

spring-boot-starter-data-rest

Spring Data REST を使用して REST で Spring Data リポジトリを公開するためのスターター

spring-boot-starter-data-solr

Spring Data Solr で Apache Solr 検索プラットフォームを使用するためのスターター

spring-boot-starter-freemarker

FreeMarker ビューを使用して MVC Web アプリケーションを構築するためのスターター

spring-boot-starter-groovy-templates

Groovy テンプレートビューを使用して MVC Web アプリケーションを構築するためのスターター

spring-boot-starter-hateoas

Spring MVC および Spring HATEOAS でハイパーメディアベースの RESTful Web アプリケーションを構築するためのスターター

spring-boot-starter-integration

Spring Integration を使用するためのスターター

spring-boot-starter-jdbc

HikariCP 接続プールで JDBC を使用するためのスターター

spring-boot-starter-jersey

JAX-RS および Jersey を使用して RESTful Web アプリケーションを構築するためのスターター。spring-boot-starter-web の代替

spring-boot-starter-jooq

jOOQ を使用して SQL データベースにアクセスするためのスターター。spring-boot-starter-data-jpa または spring-boot-starter-jdbc の代替

spring-boot-starter-json

JSON を読み書きするためのスターター

spring-boot-starter-jta-atomikos

Atomikos を使用した JTA トランザクションのスターター

spring-boot-starter-jta-bitronix

Bitronix を使用した JTA トランザクションのスターター。2.3.0 以降非推奨

spring-boot-starter-mail

Java Mail および Spring Framework のメール送信サポートを使用するためのスターター

spring-boot-starter-mustache

Mustache ビューを使用して Web アプリケーションを構築するためのスターター

spring-boot-starter-oauth2-client

Spring Security の OAuth2/OpenID Connect クライアント機能を使用するためのスターター

spring-boot-starter-oauth2-resource-server

Spring Security の OAuth2 リソースサーバー機能を使用するためのスターター

spring-boot-starter-quartz

Quartz スケジューラーを使用するためのスターター

spring-boot-starter-rsocket

RSocket クライアントおよびサーバーを構築するためのスターター

spring-boot-starter-security

Spring Security を使用するためのスターター

spring-boot-starter-test

JUnit、Hamcrest、Mockito などのライブラリを使用して Spring Boot アプリケーションをテストするためのスターター

spring-boot-starter-thymeleaf

Thymeleaf ビューを使用して MVC Web アプリケーションを構築するためのスターター

spring-boot-starter-validation

Hibernate Validator で Java Bean Validation を使用するためのスターター

spring-boot-starter-web

Spring MVC を使用して、RESTful を含む Web アプリケーションを構築するためのスターター。Tomcat をデフォルトの埋め込みコンテナーとして使用する

spring-boot-starter-web-services

Spring Web Services を使用するためのスターター

spring-boot-starter-webflux

Spring Framework の Reactive Web サポートを使用して WebFlux アプリケーションを構築するためのスターター

spring-boot-starter-websocket

Spring Framework の WebSocket サポートを使用して WebSocket アプリケーションを構築するためのスターター

アプリケーションスターターに加えて、次のスターターを使用して、本番対応機能を追加できます。

テーブル 2: Spring Boot 本番スターター
名前 説明

spring-boot-starter-actuator

Spring Boot のアクチュエーターを使用するためのスターター。アプリケーションの監視と管理に役立つ本番対応機能を提供する

最後に、Spring Boot には、特定の技術ファセットを除外または交換する場合に使用できる次のスターターも含まれています。

表 3: Spring Boot テクニカルスターター
名前 説明

spring-boot-starter-jetty

Jetty を埋め込みサーブレットコンテナーとして使用するためのスターター。spring-boot-starter-tomcat の代替

spring-boot-starter-log4j2

ロギングに Log4j2 を使用するためのスターター。spring-boot-starter-logging の代替

spring-boot-starter-logging

Logback を使用したロギングのスターター。デフォルトのロギングスターター

spring-boot-starter-reactor-netty

Reactor Netty を組み込みのリアクティブ HTTP サーバーとして使用するためのスターター。

spring-boot-starter-tomcat

Tomcat を埋め込みサーブレットコンテナーとして使用するためのスターター。spring-boot-starter-web が使用するデフォルトのサーブレットコンテナースターター

spring-boot-starter-undertow

Undertow を埋め込みサーブレットコンテナーとして使用するためのスターター。spring-boot-starter-tomcat の代替

コミュニティが提供するその他のスターターのリストについては、GitHub の spring-boot-starters モジュールの README ファイル (GitHub) を参照してください。

2. コードの構造化

Spring Boot は、動作するために特定のコードレイアウトを必要としません。ただし、役立つベストプラクティスがいくつかあります。

2.1. 「デフォルト」パッケージの使用

クラスに package 宣言が含まれていない場合、そのクラスは「デフォルトパッケージ」にあると見なされます。通常、「デフォルトパッケージ」の使用は推奨されておらず、避ける必要があります。すべての jar のすべてのクラスが読み取られるため、@ComponentScan@ConfigurationPropertiesScan@EntityScan、または @SpringBootApplication アノテーションを使用する Spring Boot アプリケーションで特定の問題を引き起こす可能性があります。

Java の推奨パッケージ命名規則に従い、逆ドメイン名(たとえば、com.example.project)を使用することをお勧めします。

2.2. メインアプリケーションクラスの特定

通常、メインアプリケーションクラスを他のクラスの上にあるルートパッケージに配置することをお勧めします。@SpringBootApplication アノテーションは多くの場合メインクラスに配置され、特定のアイテムのベース「検索パッケージ」を暗黙的に定義します。例:JPA アプリケーションを作成している場合、@SpringBootApplication アノテーション付きクラスのパッケージを使用して @Entity アイテムを検索します。ルートパッケージを使用すると、コンポーネントスキャンをプロジェクトにのみ適用することもできます。

@SpringBootApplication を使用したくない場合、インポートする @EnableAutoConfiguration および @ComponentScan アノテーションはその動作を定義するため、代わりに使用することもできます。

次のリストは、典型的なレイアウトを示しています。

com
 +- example
     +- myapplication
         +- Application.java
         |
         +- customer
         |   +- Customer.java
         |   +- CustomerController.java
         |   +- CustomerService.java
         |   +- CustomerRepository.java
         |
         +- order
             +- Order.java
             +- OrderController.java
             +- OrderService.java
             +- OrderRepository.java

Application.java ファイルは、次のように、基本的な @SpringBootApplication とともに main メソッドを宣言します。

package com.example.myapplication;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class Application {

    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }

}

3. 構成クラス

Spring Boot は Java ベースの構成を優先します。SpringApplication を XML ソースで使用することは可能ですが、通常、プライマリソースは単一の @Configuration クラスにすることをお勧めします。通常、main メソッドを定義するクラスは、プライマリ @Configuration として適切な候補です。

XML 構成を使用する多くの Spring 構成例がインターネットで公開されています。可能であれば、常に同等の Java ベースの構成を使用してください。Enable* アノテーションを検索することは、出発点として適切です。

3.1. 追加の構成クラスのインポート

すべての @Configuration を単一のクラスに入れる必要はありません。@Import アノテーションを使用して、追加の構成クラスをインポートできます。または、@ComponentScan を使用して、@Configuration クラスを含むすべての Spring コンポーネントを自動的に取得できます。

3.2. XML 設定のインポート

絶対に XML ベースの構成を使用する必要がある場合は、@Configuration クラスから開始することをお勧めします。その後、@ImportResource アノテーションを使用して XML 構成ファイルをロードできます。

4. 自動構成

Spring Boot 自動構成は、追加した jar 依存関係に基づいて、Spring アプリケーションを自動的に構成しようとします。例: HSQLDB がクラスパス上にあり、データベース接続 Bean を手動で構成していない場合、Spring Boot はメモリ内データベースを自動構成します。

@EnableAutoConfiguration または @SpringBootApplication アノテーションを @Configuration クラスの 1 つに追加して、自動構成をオプトインする必要があります。

@SpringBootApplication または @EnableAutoConfiguration アノテーションを 1 つだけ追加してください。通常、プライマリ @Configuration クラスのみにいずれかを追加することをお勧めします。

4.1. 自動構成の段階的な置き換え

自動構成は非侵襲的です。いつでも、独自の構成を定義して、自動構成の特定の部分を置き換えることができます。例:独自の DataSource Bean を追加すると、デフォルトの組み込みデータベースサポートは元に戻ります。

現在適用されている自動構成とその理由を調べる必要がある場合は、--debug スイッチを使用してアプリケーションを開始してください。これにより、選択したコアロガーのデバッグログが有効になり、コンソールに状態レポートが記録されます。

4.2. 特定の自動構成クラスを無効にする

不要な特定の自動構成クラスが適用されている場合は、次の例に示すように、@SpringBootApplication の exclude 属性を使用して無効にすることができます。

import org.springframework.boot.autoconfigure.*;
import org.springframework.boot.autoconfigure.jdbc.*;

@SpringBootApplication(exclude={DataSourceAutoConfiguration.class})
public class MyApplication {
}

クラスがクラスパス上にない場合、アノテーションの excludeName 属性を使用して、代わりに完全修飾名を指定できます。@SpringBootApplicationexclude および excludeName ではなく @EnableAutoConfiguration を使用する場合も利用できます。最後に、spring.autoconfigure.exclude プロパティを使用して、除外する自動構成クラスのリストを制御することもできます。

アノテーションレベルとプロパティの使用の両方で除外を定義できます。
自動構成クラスは public ですが、パブリック API と見なされるクラスの唯一の側面は、自動構成を無効にするために使用できるクラスの名前です。ネストされた構成クラスや Bean メソッドなど、これらのクラスの実際の内容は内部使用専用であり、直接使用することはお勧めしません。

5. Spring Bean と依存性注入

Bean とその注入された依存関係を定義するために、標準の Spring Framework 技法を自由に使用できます。簡単にするために、@ComponentScan を使用して(Bean を見つける)、@Autowired を使用して(コンストラクター注入を行う)がうまく機能することがよくあります。

上記で提案したようにコードを構成する場合(アプリケーションクラスをルートパッケージに配置する場合)、引数なしで @ComponentScan を追加できます。すべてのアプリケーションコンポーネント(@Component@Service@Repository@Controller など)は、Spring Bean として自動的に登録されます。

次の例は、コンストラクター注入を使用して必要な RiskAssessor Bean を取得する @Service Bean を示しています。

package com.example.service;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class DatabaseAccountService implements AccountService {

    private final RiskAssessor riskAssessor;

    @Autowired
    public DatabaseAccountService(RiskAssessor riskAssessor) {
        this.riskAssessor = riskAssessor;
    }

    // ...

}

Bean に 1 つのコンストラクターがある場合、次の例に示すように、@Autowired を省略できます。

@Service
public class DatabaseAccountService implements AccountService {

    private final RiskAssessor riskAssessor;

    public DatabaseAccountService(RiskAssessor riskAssessor) {
        this.riskAssessor = riskAssessor;
    }

    // ...

}
コンストラクターインジェクションを使用すると、riskAssessor フィールドが final としてマークされ、その後変更できないことを示すことに注意してください。

6. @SpringBootApplication アノテーションの使用

多くの Spring Boot 開発者は、自動構成、コンポーネントスキャンを使用し、「アプリケーションクラス」で追加の構成を定義できるアプリを好みます。単一の @SpringBootApplication アノテーションを使用して、これらの 3 つの機能を有効にできます。

  • @EnableAutoConfiguration: Spring Boot の自動構成メカニズムを有効にする

  • @ComponentScan: アプリケーションが配置されているパッケージで @Component スキャンを有効にする ( ベストプラクティスを見る)

  • @Configuration: コンテキストに追加の Bean を登録したり、追加の構成クラスをインポートしたりできます。

package com.example.myapplication;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication // same as @Configuration @EnableAutoConfiguration @ComponentScan
public class Application {

    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }

}
@SpringBootApplication は、@EnableAutoConfiguration および @ComponentScan の属性をカスタマイズするエイリアスも提供します。

これらの機能はいずれも必須ではなく、この単一のアノテーションを有効にする機能のいずれかに置き換えることもできます。たとえば、アプリケーションでコンポーネントスキャンまたは構成プロパティスキャンを使用したくない場合があります。

package com.example.myapplication;

import org.springframework.boot.SpringApplication;
import org.springframework.context.annotation.ComponentScan
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Import;

@Configuration(proxyBeanMethods = false)
@EnableAutoConfiguration
@Import({ MyConfig.class, MyAnotherConfig.class })
public class Application {

    public static void main(String[] args) {
            SpringApplication.run(Application.class, args);
    }

}

この例では、Application は、@Component アノテーション付きクラスと @ConfigurationProperties アノテーション付きクラスが自動的に検出されず、ユーザー定義 Bean が明示的にインポートされることを除いて、他の Spring Boot アプリケーションとまったく同じです(@Import を参照)。

7. アプリケーションを実行する

アプリケーションを jar としてパッケージ化し、組み込み HTTP サーバーを使用する最大の利点の 1 つは、他のアプリケーションと同じようにアプリケーションを実行できることです。Spring Boot アプリケーションのデバッグも簡単です。特別な IDE プラグインまたは拡張機能は必要ありません。

このセクションでは、jar ベースのパッケージングのみを扱います。アプリケーションを war ファイルとしてパッケージ化することを選択した場合は、サーバーと IDE のドキュメントを参照する必要があります。

7.1. IDE から実行する

IDE から Spring Boot アプリケーションを単純な Java アプリケーションとして実行できます。ただし、最初にプロジェクトをインポートする必要があります。インポート手順は、IDE とビルドシステムによって異なります。ほとんどの IDE は Maven プロジェクトを直接インポートできます。例:Eclipse ユーザーは、File メニューから Import…​ → Existing Maven Projects を選択できます。

プロジェクトを IDE に直接インポートできない場合は、ビルドプラグインを使用して IDE メタデータを生成できる場合があります。Maven には、Eclipse (Apache) および IDEA (Apache) のプラグインが含まれています。Gradle は、さまざまな IDE (英語) のプラグインを提供します。

誤って Web アプリケーションを 2 回実行すると、「Port already in use」エラーが表示されます。STS ユーザーは、Run ボタンではなく Relaunch ボタンを使用して、既存のインスタンスを確実に閉じることができます。

7.2. パッケージ化されたアプリケーションとして実行する

Spring Boot Maven または Gradle プラグインを使用して実行可能 jar を作成する場合、次の例に示すように、java -jar を使用してアプリケーションを実行できます。

$ java -jar target/myapplication-0.0.1-SNAPSHOT.jar

リモートデバッグサポートを有効にしてパッケージ化されたアプリケーションを実行することもできます。これにより、次の例に示すように、パッケージ化されたアプリケーションにデバッガーを接続できます。

$ java -Xdebug -Xrunjdwp:server=y,transport=dt_socket,address=8000,suspend=n \
       -jar target/myapplication-0.0.1-SNAPSHOT.jar

7.3. Maven プラグインの使用

Spring Boot Maven プラグインには、アプリケーションをすばやくコンパイルして実行するために使用できる run ゴールが含まれています。IDE の場合と同様に、アプリケーションは展開された形式で実行されます。次の例は、Spring Boot アプリケーションを実行する典型的な Maven コマンドを示しています。

$ mvn spring-boot:run

次の例に示すように、MAVEN_OPTS オペレーティングシステム環境変数を使用することもできます。

$ export MAVEN_OPTS=-Xmx1024m

7.4. Gradle プラグインの使用

Spring Boot Gradle プラグインには、アプリケーションを展開形式で実行するために使用できる bootRun タスクも含まれています。bootRun タスクは、org.springframework.boot および java プラグインを適用するたびに追加され、次の例に示されています。

$ gradle bootRun

次の例に示すように、JAVA_OPTS オペレーティングシステム環境変数を使用することもできます。

$ export JAVA_OPTS=-Xmx1024m

7.5. ホットスワップ

Spring Boot アプリケーションは単なる Java アプリケーションであるため、JVM ホットスワップはそのまま使用できます。JVM のホットスワップは、置き換えることができるバイトコードによって多少制限されています。より完全なソリューションを得るには、JRebel (英語) を使用できます。

spring-boot-devtools モジュールには、アプリケーションの迅速な再起動のサポートも含まれています。詳細については、この章で後述する開発ツールセクションおよびホットスワップ「使い方」を参照してください。

8. 開発ツール

Spring Boot には、アプリケーション開発エクスペリエンスをもう少し快適にすることができる追加のツールセットが含まれています。spring-boot-devtools モジュールを任意のプロジェクトに含めて、追加の開発時機能を提供できます。devtools サポートを含めるには、Maven および Gradle の次のリストに示すように、ビルドにモジュール依存関係を追加します。

Maven
<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-devtools</artifactId>
        <optional>true</optional>
    </dependency>
</dependencies>
Gradle
dependencies {
    developmentOnly("org.springframework.boot:spring-boot-devtools")
}
完全にパッケージ化されたアプリケーションを実行すると、開発者ツールは自動的に無効になります。アプリケーションが java -jar から起動された場合、または特別なクラスローダーから起動された場合、「本番アプリケーション」と見なされます。それが当てはまらない場合(つまり、コンテナーからアプリケーションを実行する場合)、devtools を除外するか、-Dspring.devtools.restart.enabled=false システムプロパティを設定することを検討してください。
Maven で依存関係にオプションのフラグを立てるか、Gradle で developmentOnly 構成を使用すると(上記のように)、プロジェクトを使用する他のモジュールに devtools が一時的に適用されなくなります。
再パッケージ化されたアーカイブには、デフォルトで devtools は含まれていません。特定のリモート devtools 機能を使用したい場合は、それを含める必要があります。Maven プラグインを使用する場合は、excludeDevtools プロパティを false に設定します。Gradle プラグインを使用する場合、developmentOnly 構成を含めるようにタスクのクラスパスを構成します

8.1. プロパティのデフォルト

Spring Boot がサポートするライブラリのいくつかは、キャッシュを使用してパフォーマンスを向上させます。例:テンプレートエンジンはコンパイル済みテンプレートをキャッシュして、テンプレートファイルの繰り返し解析を回避します。また、Spring MVC は、静的リソースを提供するときに、HTTP キャッシュヘッダーをレスポンスに追加できます。

キャッシングは本番環境では非常に有益ですが、開発中は逆効果となり、アプリケーションで行った変更を確認できなくなります。このため、spring-boot-devtools はデフォルトでキャッシュオプションを無効にします。

キャッシュオプションは通常、application.properties ファイルの設定によって構成されます。例:Thymeleaf は spring.thymeleaf.cache プロパティを提供します。spring-boot-devtools モジュールは、これらのプロパティを手動で設定する必要があるのではなく、適切な開発時構成を自動的に適用します。

Spring MVC および Spring WebFlux アプリケーションの開発中に Web リクエストに関する詳細情報が必要なため、開発者ツールは web ロギンググループの DEBUG ロギングを有効にします。これにより、受信リクエスト、処理しているハンドラー、レスポンス結果などに関する情報が得られます。すべてのリクエストの詳細(機密情報を含む可能性がある)を記録する場合は、spring.mvc.log-request-details または spring.codec.log-request-details 構成プロパティをオンにできます。

プロパティのデフォルトを適用したくない場合は、application.properties で spring.devtools.add-properties を false に設定できます。
devtools によって適用されるプロパティの完全なリストについては、DevToolsPropertyDefaultsPostProcessor (GitHub) を参照してください。

8.2. 自動再起動

spring-boot-devtools を使用するアプリケーションは、クラスパス上のファイルが変更されるたびに自動的に再起動します。これは IDE で作業するときに便利な機能です。コードの変更に対して非常に高速なフィードバックループを提供するためです。デフォルトでは、ディレクトリを指すクラスパスのエントリはすべて変更が監視されます。静的アセットやビューテンプレートなどの特定のリソースは、アプリケーションを再起動する必要がないことに注意してください。

再起動のトリガー

DevTools はクラスパスリソースを監視するため、再起動をトリガーする唯一の方法はクラスパスを更新することです。クラスパスを更新する方法は、使用している IDE によって異なります。Eclipse では、変更されたファイルを保存すると、クラスパスが更新され、再起動がトリガーされます。IntelliJ IDEA では、プロジェクト(Build +→+ Build Project)をビルドすると同じ効果があります。

フォークが有効になっている限り、サポートされているビルドプラグイン(Maven および Gradle)を使用してアプリケーションを起動することもできます。これは、DevTools が適切に動作するために独立したアプリケーションクラスローダーを必要とするためです。デフォルトでは、Gradle および Maven プラグインはアプリケーションプロセスをフォークします。
自動再起動は、LiveReload と併用すると非常にうまく機能します。詳細については、LiveReload セクションを参照してください。JRebel を使用する場合、動的なクラスの再読み込みを優先して自動再起動が無効になります。その他の devtools 機能(LiveReload やプロパティのオーバーライドなど)は引き続き使用できます。
DevTools は、アプリケーションコンテキストのシャットダウンフックに依存して、再起動中に閉じます。シャットダウンフック(SpringApplication.setRegisterShutdownHook(false))を無効にした場合、正しく機能しません。
クラスパスのエントリが変更されたときに再起動をトリガーするかどうかを決定する場合、DevTools は spring-bootspring-boot-devtoolsspring-boot-autoconfigurespring-boot-actuator および spring-boot-starter という名前のプロジェクトを自動的に無視します。
DevTools は、ApplicationContext が使用する ResourceLoader をカスタマイズする必要があります。アプリケーションがすでに提供している場合、ラップされます。ApplicationContext での getResource メソッドの直接オーバーライドはサポートされていません。
再起動とリロード

Spring Boot が提供する再起動テクノロジは、2 つのクラスローダーを使用して機能します。変更されないクラス(たとえば、サードパーティの jar からのクラス)は、基本クラスローダーにロードされます。積極的に開発しているクラスは、再起動クラスローダーにロードされます。アプリケーションを再起動すると、再起動クラスローダーが破棄され、新しいクラスローダーが作成されます。このアプローチは、基本クラスローダーがすでに利用可能であり、データが設定されているため、通常、アプリケーションの再起動は「コールドスタート」よりもはるかに高速であることを意味します。

再起動がアプリケーションに対して十分に速くない場合、またはクラスローディングの問題が発生した場合は、JRebel (英語) などのテクノロジーを ZeroTurnaround からリロードすることを検討できます。これらは、ロードされたクラスを書き換えて、リロードを受け入れやすくすることで機能します。

8.2.1. 状態評価の変更の記録

デフォルトでは、アプリケーションを再起動するたびに、状態評価デルタを示すレポートが記録されます。このレポートには、Bean の追加や削除、構成プロパティの設定などの変更を行うと、アプリケーションの自動構成に対する変更が表示されます。

レポートのログを無効にするには、次のプロパティを設定します。

spring.devtools.restart.log-condition-evaluation-delta=false

8.2.2. リソースを除外する

特定のリソースは、変更されたときに必ずしも再起動をトリガーする必要はありません。例:Thymeleaf テンプレートはその場で編集できます。デフォルトでは、/META-INF/maven/META-INF/resources/resources/static/public または /templates のリソースを変更しても再起動はトリガーされませんが、ライブリロードはトリガーされます。これらの除外をカスタマイズする場合は、spring.devtools.restart.exclude プロパティを使用できます。例: /static と /public のみを除外するには、次のプロパティを設定します。

spring.devtools.restart.exclude=static/**,public/**
これらのデフォルトを維持して除外を追加する場合は、代わりに spring.devtools.restart.additional-exclude プロパティを使用します。

8.2.3. 追加のパスを見る

クラスパスにないファイルに変更を加えた場合、アプリケーションを再起動または再ロードすることができます。これを行うには、spring.devtools.restart.additional-paths プロパティを使用して、変更を監視する追加のパスを構成します。前述の spring.devtools.restart.exclude プロパティを使用して、追加のパスにある変更が完全な再起動またはライブリロードをトリガーするかどうかを制御できます。

8.2.4. 再起動を無効にする

再起動機能を使用しない場合は、spring.devtools.restart.enabled プロパティを使用して無効にすることができます。ほとんどの場合、application.properties でこのプロパティを設定できます(そうすると、再起動クラスローダーが初期化されますが、ファイルの変更は監視されません)。

再起動サポートを完全に無効にする必要がある場合(たとえば、特定のライブラリで動作しないため)、次の例に示すように、SpringApplication.run(…​) を呼び出す前に spring.devtools.restart.enabledSystem プロパティを false に設定する必要があります。

public static void main(String[] args) {
    System.setProperty("spring.devtools.restart.enabled", "false");
    SpringApplication.run(MyApp.class, args);
}

8.2.5. トリガーファイルの使用

変更されたファイルを継続的にコンパイルする IDE を使用している場合、特定の時間にのみ再起動をトリガーすることをお勧めします。そのためには、「トリガーファイル」を使用できます。これは、実際に再起動チェックをトリガーするときに変更する必要がある特別なファイルです。

ファイルを更新すると、チェックがトリガーされますが、再起動は、Devtools が何らかの処理を行うことを検出した場合にのみ実際に発生します。

トリガーファイルを使用するには、spring.devtools.restart.trigger-file プロパティをトリガーファイルの名前(パスを除く)に設定します。トリガーファイルは、クラスパスのどこかに表示する必要があります。

例:次の構造のプロジェクトがある場合:

src
+- main
   +- resources
      +- .reloadtrigger

trigger-file プロパティは次のようになります。

spring.devtools.restart.trigger-file=.reloadtrigger

再起動は、src/main/resources/.reloadtrigger が更新されたときにのみ発生します。

すべてのプロジェクトが同じように動作するように、spring.devtools.restart.trigger-file をグローバル設定として設定できます。

一部の IDE には、トリガーファイルの手動更新を不要にする機能があります。Eclipse Pleiades All in One (STS, Lombok 付属) または Eclipse 用 Spring Tools (英語) IntelliJ IDEA (Ultimate エディション) は両方ともそのようなサポートを持っています。Spring Tools では、コンソールビューから「リロード」ボタンを使用できます(trigger-file の名前が .reloadtrigger である限り)。IntelliJ については、このドキュメントの指示に従ってください。

8.2.6. 再起動クラスローダーのカスタマイズ

再起動とリロードセクションで前述したように、再起動機能は 2 つのクラスローダーを使用して実装されます。ほとんどのアプリケーションでは、このアプローチはうまく機能します。ただし、クラスロードの問題が発生する場合があります。

デフォルトでは、IDE で開いているプロジェクトはすべて「再起動」クラスローダーでロードされ、通常の .jar ファイルは「ベース」クラスローダーでロードされます。すべてのモジュールが IDE にインポートされるわけではなく、マルチモジュールプロジェクトで作業している場合は、カスタマイズが必要になる場合があります。そのためには、META-INF/spring-devtools.properties ファイルを作成できます。

spring-devtools.properties ファイルには、restart.exclude および restart.include というプレフィックスが付いたプロパティを含めることができます。include 要素は「再起動」クラスローダーにプルアップする必要があるアイテムであり、exclude 要素は「ベース」クラスローダーにプッシュダウンする必要があるアイテムです。次の例に示すように、プロパティの値はクラスパスに適用される正規表現パターンです。

restart.exclude.companycommonlibs=/mycorp-common-[\\w\\d-\.]+\.jar
restart.include.projectcommon=/mycorp-myproj-[\\w\\d-\.]+\.jar
すべてのプロパティキーは一意である必要があります。プロパティが restart.include. または restart.exclude. で始まる限り、考慮されます。
クラスパスからのすべての META-INF/spring-devtools.properties がロードされます。プロジェクト内、またはプロジェクトが使用するライブラリ内にファイルをパッケージ化できます。

8.2.7. 既知の制限

再起動機能は、標準の ObjectInputStream を使用してデシリアライズされたオブジェクトではうまく機能しません。データをデシリアライズする必要がある場合は、Spring の ConfigurableObjectInputStream を Thread.currentThread().getContextClassLoader() と組み合わせて使用する必要がある場合があります。

残念ながら、いくつかのサードパーティライブラリは、コンテキストクラスローダーを考慮せずにデシリアライズします。このような問題を見つけた場合は、元の作者に修正を依頼する必要があります。

8.3. LiveReload

spring-boot-devtools モジュールには、リソースが変更されたときにブラウザーのリフレッシュをトリガーするために使用できる LiveReload サーバーが組み込まれています。LiveReload ブラウザー拡張機能は、livereload.com (英語) から Chrome、Firefox、および Safari で自由に使用できます。

アプリケーションの実行時に LiveReload サーバーを開始したくない場合は、spring.devtools.livereload.enabled プロパティを false に設定できます。

一度に実行できる LiveReload サーバーは 1 つだけです。アプリケーションを開始する前に、他の LiveReload サーバーが実行されていないことを確認してください。IDE から複数のアプリケーションを起動する場合、最初のアプリケーションのみが LiveReload をサポートしています。

8.4. グローバル設定

以下のファイルのいずれかを $HOME/.config/spring-boot ディレクトリに追加することにより、グローバル devtools 設定を構成できます。

  1. spring-boot-devtools.properties

  2. spring-boot-devtools.yaml

  3. spring-boot-devtools.yml

これらのファイルに追加されたプロパティは、devtools を使用するマシン上のすべての Spring Boot アプリケーションに適用されます。例:常にトリガーファイルを使用するように再起動を構成するには、次のプロパティを追加します。

〜 / .config/spring-boot/spring-boot-devtools.properties
spring.devtools.restart.trigger-file=.reloadtrigger
$HOME/.config/spring-boot に devtools 構成ファイルが見つからない場合、$HOME ディレクトリのルートで .spring-boot-devtools.properties ファイルの存在が検索されます。これにより、$HOME/.config/spring-boot の場所をサポートしない古いバージョンの Spring Boot にあるアプリケーションと devtools グローバル構成を共有できます。

プロファイルは、devtools プロパティ / yaml ファイルではサポートされていません。

.spring-boot-devtools.properties でアクティブ化されたプロファイルは、プロファイル固有の構成ファイルのロードに影響を与えません。YAML ファイル内のプロファイル固有のファイル名(spring-boot-devtools-<profile>.properties 形式)および spring.profile サブドキュメントはサポートされていません。

8.4.1. File System Watcher の構成

FileSystemWatcher (GitHub) は、一定の時間間隔でクラスの変更をポーリングし、事前定義された待機期間を待って、変更がないことを確認することによって機能します。Spring Boot は IDE に完全に依存して、Spring Boot がファイルを読み取れる場所にファイルをコンパイルおよびコピーするため、devtools がアプリケーションを再起動したときに特定の変更が反映されない場合があります。このような問題が常に発生する場合は、spring.devtools.restart.poll-interval および spring.devtools.restart.quiet-period パラメーターを開発環境に適した値に増やしてみてください。

spring.devtools.restart.poll-interval=2s
spring.devtools.restart.quiet-period=1s

監視対象のクラスパスディレクトリが 2 秒ごとにポーリングされて変更が確認され、追加のクラス変更がないことを確認するために 1 秒の待機期間が維持されます。

8.5. リモートアプリケーション

Spring Boot 開発者ツールは、ローカル開発に限定されません。アプリケーションをリモートで実行するときに、いくつかの機能を使用することもできます。リモートサポートはオプトインです。これを有効にするとセキュリティ上のリスクになる可能性があります。信頼できるネットワークで実行している場合、または SSL で保護されている場合にのみ有効にしてください。これらのオプションのいずれも使用できない場合は、DevTools ' リモートサポートを使用しないでください。本番デプロイでサポートを有効にしないでください。

有効にするには、次のリストに示すように、devtools が再パッケージ化されたアーカイブに含まれていることを確認する必要があります。

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <configuration>
                <excludeDevtools>false</excludeDevtools>
            </configuration>
        </plugin>
    </plugins>
</build>

次に、spring.devtools.remote.secret プロパティを設定する必要があります。重要なパスワードやシークレットと同様に、値は一意で強力で、推測や総当たり攻撃ができないようにする必要があります。

リモート devtools サポートは 2 つの部分で提供されます。接続を受け入れるサーバー側エンドポイントと、IDE で実行するクライアントアプリケーションです。spring.devtools.remote.secret プロパティが設定されると、サーバーコンポーネントは自動的に有効になります。クライアントコンポーネントは手動で起動する必要があります。

8.5.1. リモートクライアントアプリケーションの実行

リモートクライアントアプリケーションは、IDE 内から実行されるように設計されています。接続するリモートプロジェクトと同じクラスパスで org.springframework.boot.devtools.RemoteSpringApplication を実行する必要があります。アプリケーションの単一の必須引数は、接続先のリモート URL です。

例:Eclipse または STS を使用していて、Cloud Foundry にデプロイした my-app という名前のプロジェクトがある場合、次のようにします。

  • Run メニューから Run Configurations…​ を選択します。

  • 新しい Java Application 「起動構成」を作成します。

  • my-app プロジェクトを参照します。

  • org.springframework.boot.devtools.RemoteSpringApplication をメインクラスとして使用します。

  • https://myapp.cfapps.io を Program arguments (またはリモートの URL)に追加します。

実行中のリモートクライアントは、次のリストのようになります。

  .   ____          _                                              __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _          ___               _      \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` |        | _ \___ _ __  ___| |_ ___ \ \ \ \
 \\/  ___)| |_)| | | | | || (_| []::::::[]   / -_) '  \/ _ \  _/ -_) ) ) ) )
  '  |____| .__|_| |_|_| |_\__, |        |_|_\___|_|_|_\___/\__\___|/ / / /
 =========|_|==============|___/===================================/_/_/_/
 :: Spring Boot Remote :: 2.3.1.RELEASE

2015-06-10 18:25:06.632  INFO 14938 --- [           main] o.s.b.devtools.RemoteSpringApplication   : Starting RemoteSpringApplication on pwmbp with PID 14938 (/Users/pwebb/projects/spring-boot/code/spring-boot-project/spring-boot-devtools/target/classes started by pwebb in /Users/pwebb/projects/spring-boot/code)
2015-06-10 18:25:06.671  INFO 14938 --- [           main] s.c.a.AnnotationConfigApplicationContext : Refreshing org.spring[email protected] (英語)  2a17b7b6: startup date [Wed Jun 10 18:25:06 PDT 2015]; root of context hierarchy
2015-06-10 18:25:07.043  WARN 14938 --- [           main] o.s.b.d.r.c.RemoteClientConfiguration    : The connection to http://localhost:8080 is insecure. You should use a URL starting with 'https://'.
2015-06-10 18:25:07.074  INFO 14938 --- [           main] o.s.b.d.a.OptionalLiveReloadServer       : LiveReload server is running on port 35729
2015-06-10 18:25:07.130  INFO 14938 --- [           main] o.s.b.devtools.RemoteSpringApplication   : Started RemoteSpringApplication in 0.74 seconds (JVM running for 1.105)
リモートクライアントは実際のアプリケーションと同じクラスパスを使用しているため、アプリケーションプロパティを直接読み取ることができます。これにより、spring.devtools.remote.secret プロパティが読み取られ、認証のためにサーバーに渡されます。
接続プロトコルとして https:// を使用することを常にお勧めします。これにより、トラフィックが暗号化され、パスワードを傍受できなくなります。
プロキシを使用してリモートアプリケーションにアクセスする必要がある場合は、spring.devtools.remote.proxy.host および spring.devtools.remote.proxy.port プロパティを構成します。

8.5.2. リモートアップデート

リモートクライアントは、ローカル再起動と同じ方法でアプリケーションクラスパスの変更を監視します。更新されたリソースはすべてリモートアプリケーションにプッシュされ、(必要な場合)再起動をトリガーします。これは、ローカルにないクラウドサービスを使用する機能を反復する場合に役立ちます。一般的に、リモートの更新と再起動は、完全な再構築とデプロイのサイクルよりもはるかに高速です。

遅い開発環境では、沈黙期間が十分ではなく、クラスの変更がバッチに分割される場合があります。クラス変更の最初のバッチがアップロードされた後、サーバーが再起動されます。サーバーが再起動しているため、次のバッチをアプリケーションに送信できません。

これは通常、一部のクラスのアップロードの失敗に関する RemoteSpringApplication ログの警告と、その結果の再試行によって明示されます。ただし、変更の最初のバッチがアップロードされた後、アプリケーションコードの不整合や再起動の失敗につながる可能性もあります。このような問題が常に発生する場合は、spring.devtools.restart.poll-interval および spring.devtools.restart.quiet-period パラメーターを開発環境に適した値に増やしてみてください。これらのプロパティの設定については、File System Watcher の構成セクションを参照してください。

ファイルは、リモートクライアントが実行されている場合にのみ監視されます。リモートクライアントを開始する前にファイルを変更した場合、そのファイルはリモートサーバーにプッシュされません。

9. 本番用にアプリケーションをパッケージ化する

実行可能 jar は、実動デプロイに使用できます。自己完結型であるため、クラウドベースのデプロイにも最適です。

ヘルス、監査、メトリック REST または JMX エンドポイントなどの追加の「本番対応」機能については、spring-boot-actuator の追加を検討してください。詳細については、production-ready-features.html を参照してください。

10. 次のステップ

Spring Boot の使用方法と、従うべきいくつかのベストプラクティスを理解する必要があります。これで、特定の Spring Boot の機能 詳細を学ぶことができます。または、スキップして Spring Boot の「本番対応」の特徴について読むこともできます。

Unofficial Translation by spring.pleiades.io. See the original content.