開発者ツール
Spring Boot には、アプリケーション開発エクスペリエンスをもう少し快適にすることができる追加のツールセットが含まれています。spring-boot-devtools
モジュールを任意のプロジェクトに含めて、追加の開発時機能を提供できます。devtools サポートを含めるには、Maven および Gradle の次のように、ビルドにモジュール依存関係を追加します。
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-devtools</artifactId>
<optional>true</optional>
</dependency>
</dependencies>
dependencies {
developmentOnly("org.springframework.boot:spring-boot-devtools")
}
Devtools は、特にマルチモジュールプロジェクトで、クラスローディングの課題を引き起こす可能性があります。クラスローディングの課題の診断は、診断して解決する方法を説明しています。 |
完全にパッケージ化されたアプリケーションを実行すると、開発者ツールは自動的に無効になります。アプリケーションが java -jar から起動された場合、または特別なクラスローダーから起動された場合、「本番アプリケーション」と見なされます。この動作は、spring.devtools.restart.enabled システムプロパティを使用して制御できます。アプリケーションの起動に使用されるクラスローダーに関係なく、devtools を有効にするには、-Dspring.devtools.restart.enabled=true システムプロパティを設定します。これは、devtools の実行がセキュリティリスクとなる本番環境では実行しないでください。devtools を無効にするには、依存関係を除外するか、-Dspring.devtools.restart.enabled=false システムプロパティを設定します。 |
Maven で依存関係にオプションのフラグを立てるか、Gradle で developmentOnly 構成を使用すると(上記のように)、プロジェクトを使用する他のモジュールに devtools が一時的に適用されなくなります。 |
再パッケージ化されたアーカイブには、デフォルトでは devtools が含まれません。特定のリモート devtools 機能を使用したい場合は、それを含める必要があります。Maven プラグインを使用する場合は、excludeDevtools プロパティを false に設定します。Gradle プラグインを使用する場合は、developmentOnly 構成を含むようにタスクのクラスパスを構成します。 |
クラスローディングの課題の診断
再起動とリロードセクションに従って、再起動機能は 2 つのクラスローダーを使用して実装されます。ほとんどのアプリケーションでは、このアプローチが適切に機能します。ただし、特にマルチモジュールプロジェクトでは、クラスローディングの問題が発生する場合があります。
クラスローディングの課題が実際に devtools とその 2 つのクラスローダーによって引き起こされているかどうかを診断するには、restart を無効にしてみてください。これで課題が解決した場合は、プロジェクト全体が含まれるようにリスタートクラスローダーをカスタマイズします。
プロパティのデフォルト
Spring Boot がサポートするライブラリのいくつかは、キャッシュを使用してパフォーマンスを向上させます。例: テンプレートエンジンは、コンパイルされたテンプレートをキャッシュして、テンプレートファイルを繰り返し解析しないようにします。また、Spring MVC は、静的リソースを提供するときに、レスポンスに HTTP キャッシングヘッダーを追加できます。
キャッシュは本番環境では非常に有益ですが、開発中は逆効果になる可能性があり、アプリケーションで行った変更を確認できなくなります。このため、spring-boot-devtools はデフォルトでキャッシュオプションを無効にします。
キャッシュオプションは通常、application.properties
ファイルの設定によって構成されます。例: Thymeleaf は spring.thymeleaf.cache
プロパティを提供します。spring-boot-devtools
モジュールは、これらのプロパティを手動で設定する必要があるのではなく、適切な開発時構成を自動的に適用します。
次の表に、適用されるすべてのプロパティを示します。
名前 | デフォルト値 |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
プロパティのデフォルトを適用したくない場合は、application.properties で spring.devtools.add-properties を false に設定できます。 |
Spring MVC および Spring WebFlux アプリケーションの開発中に Web リクエストに関する詳細情報が必要になるため、開発者ツールでは、web
ロギンググループに対して DEBUG
ロギングを有効にすることをお勧めします。これにより、受信リクエスト、それを処理しているハンドラー、レスポンス結果、その他の詳細に関する情報が得られます。すべてのリクエストの詳細(機密情報を含む)をログに記録する場合は、spring.mvc.log-request-details
または spring.codec.log-request-details
構成プロパティをオンにすることができます。
自動再起動
spring-boot-devtools
を使用するアプリケーションは、クラスパス上のファイルが変更されるたびに自動的に再起動します。これは IDE で作業するときに便利な機能です。コードの変更に対して非常に高速なフィードバックループを提供するためです。デフォルトでは、ディレクトリを指すクラスパスのエントリはすべて変更が監視されます。静的アセットやビューテンプレートなどの特定のリソースは、アプリケーションを再起動する必要がないことに注意してください。
ビルドプラグインを使用して Maven または Gradle で再起動する場合は、forking を enabled に設定したままにする必要があります。フォークを無効にすると、devtools によって使用される分離されたアプリケーションクラスローダーが作成されず、再起動が正しく動作しません。 |
自動再起動は、LiveReload と併用すると非常にうまく機能します。詳細については、LiveReload セクションを参照してください。JRebel を使用する場合、動的なクラスの再読み込みを優先して自動再起動は無効になります。その他の devtools 機能 (LiveReload やプロパティのオーバーライドなど) は引き続き使用できます。 |
DevTools は、アプリケーションコンテキストのシャットダウンフックに依存して、再起動中に閉じます。シャットダウンフック(SpringApplication.setRegisterShutdownHook(false) )を無効にした場合、正しく機能しません。 |
DevTools は、ApplicationContext (Javadoc) で使用される ResourceLoader (Javadoc) をカスタマイズする必要があります。アプリケーションがすでに提供している場合は、ラップされます。ApplicationContext (Javadoc) 上の getResource メソッドの直接オーバーライドはサポートされていません。 |
AspectJ ウィービングを使用している場合、自動再起動はサポートされていません。 |
条件評価における変更のロギング
デフォルトでは、アプリケーションを再起動するたびに、状態評価デルタを示すレポートが記録されます。このレポートには、Bean の追加や削除、構成プロパティの設定などの変更を行うと、アプリケーションの自動構成に対する変更が表示されます。
レポートのログを無効にするには、次のプロパティを設定します。
プロパティ
YAML
spring.devtools.restart.log-condition-evaluation-delta=false
spring:
devtools:
restart:
log-condition-evaluation-delta: false
リソースを除外する
特定のリソースは、変更されたときに必ずしも再起動をトリガーする必要はありません。例: Thymeleaf テンプレートはその場で編集できます。デフォルトでは、/META-INF/maven
、/META-INF/resources
、/resources
、/static
、/public
または /templates
のリソースを変更しても再起動はトリガーされませんが、ライブリロードはトリガーされます。これらの除外をカスタマイズする場合は、spring.devtools.restart.exclude
プロパティを使用できます。例: /static
と /public
のみを除外するには、次のプロパティを設定します。
プロパティ
YAML
spring.devtools.restart.exclude=static/**,public/**
spring:
devtools:
restart:
exclude: "static/**,public/**"
これらのデフォルトを維持して除外を追加する場合は、代わりに spring.devtools.restart.additional-exclude プロパティを使用します。 |
再起動を無効にする
再起動機能を使用しない場合は、spring.devtools.restart.enabled
プロパティを使用して無効にすることができます。ほとんどの場合、application.properties
でこのプロパティを設定できます(そうすると、再起動クラスローダーが初期化されますが、ファイルの変更は監視されません)。
再起動サポートを完全に無効にする必要がある場合 (たとえば、特定のライブラリでは機能しないため)、次の例に示すように、SpringApplication.run(…)
を呼び出す前に、spring.devtools.restart.enabled
System
(標準 Javadoc) プロパティを false
に設定する必要があります。
Java
Kotlin
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
@SpringBootApplication
public class MyApplication {
public static void main(String[] args) {
System.setProperty("spring.devtools.restart.enabled", "false");
SpringApplication.run(MyApplication.class, args);
}
}
import org.springframework.boot.SpringApplication
import org.springframework.boot.autoconfigure.SpringBootApplication
@SpringBootApplication
object MyApplication {
@JvmStatic
fun main(args: Array<String>) {
System.setProperty("spring.devtools.restart.enabled", "false")
SpringApplication.run(MyApplication::class.java, *args)
}
}
トリガーファイルの使用
変更されたファイルを継続的にコンパイルする IDE を使用している場合、特定の時間にのみ再起動をトリガーすることをお勧めします。そのためには、「トリガーファイル」を使用できます。これは、実際に再起動チェックをトリガーするときに変更する必要がある特別なファイルです。
ファイルを更新すると、チェックがトリガーされますが、再起動は、Devtools が何らかの処理を行うことを検出した場合にのみ実際に発生します。 |
トリガーファイルを使用するには、spring.devtools.restart.trigger-file
プロパティをトリガーファイルの名前(パスを除く)に設定します。トリガーファイルは、クラスパスのどこかに表示する必要があります。
例: 次の構造のプロジェクトがある場合:
src
+- main
+- resources
+- .reloadtrigger
trigger-file
プロパティは次のようになります。
プロパティ
YAML
spring.devtools.restart.trigger-file=.reloadtrigger
spring:
devtools:
restart:
trigger-file: ".reloadtrigger"
再起動は、src/main/resources/.reloadtrigger
が更新されたときにのみ発生します。
すべてのプロジェクトが同じように動作するように、spring.devtools.restart.trigger-file をグローバル設定として設定できます。 |
一部の IDE には、トリガーファイルの手動更新を不要にする機能があります。Pleiades All in One (JDK, STS, Lombok 付属) または Eclipse 用 Spring Tools (英語) と IntelliJ IDEA (Ultimate エディション) (英語) は両方ともそのようなサポートを持っています。Spring Tools では、コンソールビューから「リロード」ボタンを使用できます(trigger-file
の名前が .reloadtrigger
である限り)。IntelliJ IDEA については、このドキュメントの指示 (英語) に従ってください。
再起動クラスローダーのカスタマイズ
前述の再起動とリロードセクションで説明したように、再起動機能は 2 つのクラスローダーを使用して実装されます。これにより問題が発生する場合は、spring.devtools.restart.enabled
システムプロパティを使用して課題を診断できます。また、再起動をオフにした状態でアプリが動作する場合は、どのクラスローダーによって何がロードされるかをカスタマイズする必要がある可能性があります。
デフォルトでは、IDE で開いているプロジェクトはすべて「再起動」クラスローダーでロードされ、通常の .jar
ファイルはすべて「ベース」クラスローダーでロードされます。mvn spring-boot:run
または gradle bootRun
を使用する場合も同様です。@SpringBootApplication
(Javadoc) を含むプロジェクトは「再起動」クラスローダーでロードされ、その他すべては「ベース」クラスローダーでロードされます。クラスパスはアプリを起動するとコンソールに表示されるため、問題のあるエントリを特定できます。リフレクションによって使用されるクラス、特にアノテーションは、起動時に使用するアプリケーションクラスよりも前に親 (固定) クラスローダーにロードされる可能性があり、これによりアプリケーションで Spring によって検出されない可能性があります。
META-INF/spring-devtools.properties
ファイルを作成することで、Spring Boot にプロジェクトの一部を別のクラスローダーでロードするように指示できます。spring-devtools.properties
ファイルには、restart.exclude
および restart.include
というプレフィックスが付いたプロパティを含めることができます。include
要素は「再起動」クラスローダーにプルアップされる項目であり、exclude
要素は「ベース」クラスローダーにプッシュダウンされる項目です。プロパティの値は、起動時に JVM に渡されるクラスパスに適用される正規表現パターンです。次の例では、一部のローカルクラスファイルが除外され、一部の追加ライブラリが再起動クラスローダーに含まれています。
restart:
exclude:
companycommonlibs: "/mycorp-common-[\\w\\d-\\.]/(build|bin|out|target)/"
include:
projectcommon: "/mycorp-myproj-[\\w\\d-\\.]+\\.jar"
すべてのプロパティキーは一意である必要があります。プロパティが restart.include. または restart.exclude. で始まる限り、考慮されます。 |
クラスパスからのすべての META-INF/spring-devtools.properties がロードされます。プロジェクト内、またはプロジェクトが使用するライブラリ内にファイルをパッケージ化できます。システムプロパティは使用できません。プロパティファイルのみ使用できます。 |
既知の制限
再起動機能は、標準の ObjectInputStream
(標準 Javadoc) を使用してデシリアライズされたオブジェクトでは適切に動作しません。データをデシリアライズする必要がある場合は、Spring の ConfigurableObjectInputStream
(Javadoc) を Thread.currentThread().getContextClassLoader()
と組み合わせて使用する必要があります。
残念ながら、いくつかのサードパーティライブラリは、コンテキストクラスローダーを考慮せずにデシリアライズします。このような問題を見つけた場合は、元の作者に修正を依頼する必要があります。
LiveReload
spring-boot-devtools
モジュールには、リソースが変更されたときにブラウザーのリフレッシュをトリガーするために使用できる組み込み LiveReload サーバーが含まれています。LiveReload ブラウザー拡張機能は、Chrome、Firefox、Safari でフリーで利用できます。これらの拡張機能は、選択したブラウザーのマーケットプレイスまたはストアで "LiveReload" を検索すると見つかります。
アプリケーションの実行時に LiveReload サーバーを開始したくない場合は、spring.devtools.livereload.enabled
プロパティを false
に設定できます。
一度に実行できる LiveReload サーバーは 1 つだけです。アプリケーションを開始する前に、他の LiveReload サーバーが実行されていないことを確認してください。IDE から複数のアプリケーションを起動する場合、最初のアプリケーションのみが LiveReload をサポートしています。 |
ファイルが変更されたときに LiveReload をトリガーするには、自動再起動を有効にする必要があります。 |
グローバル設定
以下のファイルのいずれかを $HOME/.config/spring-boot
ディレクトリに追加することにより、グローバル devtools 設定を構成できます。
spring-boot-devtools.properties
spring-boot-devtools.yaml
spring-boot-devtools.yml
これらのファイルに追加されたプロパティはすべて、 devtools を使用するマシン上のすべての Spring Boot アプリケーションに適用されます。例: 常にトリガーファイルを使用するように再起動を構成するには、spring-boot-devtools
ファイルに次のプロパティを追加します。
プロパティ
YAML
spring.devtools.restart.trigger-file=.reloadtrigger
spring:
devtools:
restart:
trigger-file: ".reloadtrigger"
デフォルトでは、$HOME
はユーザーのホームディレクトリです。この場所をカスタマイズするには、SPRING_DEVTOOLS_HOME
環境変数または spring.devtools.home
システムプロパティを設定します。
$HOME/.config/spring-boot に devtools 構成ファイルが見つからない場合、$HOME ディレクトリのルートで .spring-boot-devtools.properties ファイルの存在が検索されます。これにより、$HOME/.config/spring-boot の場所をサポートしない古いバージョンの Spring Boot にあるアプリケーションと devtools グローバル構成を共有できます。 |
プロファイルは、devtools プロパティ / yaml ファイルではサポートされていません。
|
File System Watcher の構成
FileSystemWatcher
(Javadoc) は、一定の時間間隔でクラスの変更をポーリングし、その後、定義済みの待機期間を待って、それ以上の変更がないことを確認します。Spring Boot は、ファイルをコンパイルして Spring Boot が読み取れる場所にコピーするのに IDE に完全に依存しているため、devtools がアプリケーションを再起動したときに特定の変更が反映されない場合があります。このような問題が頻繁に発生する場合は、spring.devtools.restart.poll-interval
および spring.devtools.restart.quiet-period
パラメーターを開発環境に適した値に増やしてみてください。
プロパティ
YAML
spring.devtools.restart.poll-interval=2s
spring.devtools.restart.quiet-period=1s
spring:
devtools:
restart:
poll-interval: "2s"
quiet-period: "1s"
監視対象のクラスパスディレクトリが 2 秒ごとにポーリングされて変更が確認され、追加のクラス変更がないことを確認するために 1 秒の待機期間が維持されます。
リモートアプリケーション
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
プロパティが設定されると、サーバーコンポーネントは自動的に有効になります。クライアントコンポーネントは手動で起動する必要があります。
リモート devtools は、Spring WebFlux アプリケーションではサポートされていません。 |
リモートクライアントアプリケーションの実行
リモートクライアントアプリケーションは、IDE 内から実行できるように設計されています。接続先の リモートプロジェクトと同じクラスパスで RemoteSpringApplication
(Javadoc) を実行する必要があります。アプリケーションの必須引数は、接続先の リモート URL のみです。
例: Eclipse または Spring Tools を使用していて、Cloud Foundry にデプロイした my-app
という名前のプロジェクトがある場合は、次のようにします。
Run
メニューからRun Configurations…
を選択します。新しい
Java Application
「起動構成」を作成します。my-app
プロジェクトを参照します。メインクラスとして
RemoteSpringApplication
(Javadoc) を使用します。https://myapp.cfapps.io
をProgram arguments
(またはリモートの URL)に追加します。
実行中のリモートクライアントは、次のようになります。
. ____ _ __ _ _
/\\ / ___'_ __ _ _(_)_ __ __ _ ___ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | | _ \___ _ __ ___| |_ ___ \ \ \ \
\\/ ___)| |_)| | | | | || (_| []::::::[] / -_) ' \/ _ \ _/ -_) ) ) ) )
' |____| .__|_| |_|_| |_\__, | |_|_\___|_|_|_\___/\__\___|/ / / /
=========|_|==============|___/===================================/_/_/_/
:: Spring Boot Remote :: (v3.4.1)
2024-12-19T12:20:09.332Z INFO 126743 --- [ main] o.s.b.devtools.RemoteSpringApplication : Starting RemoteSpringApplication v3.4.1 using Java 17.0.13 with PID 126743 (/Users/myuser/.m2/repository/org/springframework/boot/spring-boot-devtools/3.4.1/spring-boot-devtools-3.4.1.jar started by myuser in /opt/apps/)
2024-12-19T12:20:09.342Z INFO 126743 --- [ main] o.s.b.devtools.RemoteSpringApplication : No active profile set, falling back to 1 default profile: "default"
2024-12-19T12:20:10.349Z INFO 126743 --- [ main] o.s.b.d.a.OptionalLiveReloadServer : LiveReload server is running on port 35729
2024-12-19T12:20:10.445Z INFO 126743 --- [ main] o.s.b.devtools.RemoteSpringApplication : Started RemoteSpringApplication in 2.826 seconds (process running for 3.85)
リモートクライアントは実際のアプリケーションと同じクラスパスを使用しているため、アプリケーションプロパティを直接読み取ることができます。これにより、spring.devtools.remote.secret プロパティが読み取られ、認証のためにサーバーに渡されます。 |
接続プロトコルとして https:// を使用することを常にお勧めします。これにより、トラフィックが暗号化され、パスワードをインターセプトできなくなります。 |
プロキシを使用してリモートアプリケーションにアクセスする必要がある場合は、spring.devtools.remote.proxy.host および spring.devtools.remote.proxy.port プロパティを構成します。 |
リモートアップデート
リモートクライアントは、ローカル再起動と同じ方法でアプリケーションクラスパスの変更を監視します。更新されたリソースはすべてリモートアプリケーションにプッシュされ、(必要な場合)再起動をトリガーします。これは、ローカルにないクラウドサービスを使用する機能を反復する場合に役立ちます。一般的に、リモートの更新と再起動は、完全な再構築とデプロイのサイクルよりもはるかに高速です。
遅い開発環境では、沈黙期間が十分ではなく、クラスの変更がバッチに分割される場合があります。クラス変更の最初のバッチがアップロードされた後、サーバーが再起動されます。サーバーが再起動しているため、次のバッチをアプリケーションに送信できません。
これは通常、一部のクラスのアップロードに失敗し、その結果再試行が行われるという警告が RemoteSpringApplication
(Javadoc) ログに記録されることによって示されます。ただし、最初の変更バッチがアップロードされた後にアプリケーションコードの不整合が発生し、再起動が失敗する可能性もあります。このような問題が頻繁に発生する場合は、spring.devtools.restart.poll-interval
および spring.devtools.restart.quiet-period
パラメーターを開発環境に適した値に増やしてみてください。これらのプロパティの構成については、File System Watcher の構成セクションを参照してください。
ファイルは、リモートクライアントが実行されている場合にのみ監視されます。リモートクライアントを開始する前にファイルを変更した場合、そのファイルはリモートサーバーにプッシュされません。 |