このセクションでは、Spring Bootを使用するときによく発生するいくつかの一般的な「それを行う方法」の質問に対する回答を提供します。そのカバレッジは網羅的ではありませんが、非常に多くの部分をカバーしています。

ここで取り上げていない特定の問題がある場合は、stackoverflow.com(英語) をチェックして、誰かがすでに回答を提供しているかどうかを確認します。また、新しい質問をするのに最適な場所です（ spring-boot タグを使用してください）。

また、このセクションを拡充できることは我々にとっても幸せです。「使い方」を追加する場合は、プルリクエスト(GitHub) を送信してください。

1. Spring Bootアプリケーション

このセクションには、Spring Bootアプリケーションに直接関連するトピックが含まれています。

1.1. 独自のFailureAnalyzerを作成する

FailureAnalyzer (Javadoc) は、起動時に例外をインターセプトし、それを FailureAnalysis (Javadoc) にラップされた人間が読み取れるメッセージに変換する優れた方法です。Spring Bootは、アプリケーションコンテキスト関連の例外、JSR-303検証などのためのこのようなアナライザーを提供します。独自に作成することもできます。

AbstractFailureAnalyzer は、FailureAnalyzer の便利な拡張機能であり、処理する例外の指定された例外タイプの存在を確認します。それを継承して、実装が例外が実際に存在する場合にのみ例外を処理する機会を得ることができます。何らかの理由で例外を処理できない場合は、null を返して、別の実装に例外を処理する機会を与えます。

FailureAnalyzer 実装は META-INF/spring.factoriesに登録する必要があります。次の例では、ProjectConstraintViolationFailureAnalyzerを登録します。

org.springframework.boot.diagnostics.FailureAnalyzer=\
com.example.ProjectConstraintViolationFailureAnalyzer
BeanFactory または Environmentにアクセスする必要がある場合、FailureAnalyzer はそれぞれ BeanFactoryAware または EnvironmentAware をそれぞれ実装できます。

1.2. 自動構成のトラブルシューティング

Spring Boot自動構成は、「正しい動作をする」ために最善を尽くしますが、時には失敗することがあり、その理由を説明するのは難しい場合があります。

Spring Boot ApplicationContextには、本当に便利な ConditionEvaluationReport があります。 DEBUG ロギング出力を有効にすると、それを見ることができます。 spring-boot-actuator を使用する場合（ アクチュエーターの章を参照）、JSONでレポートをレンダリングする conditions エンドポイントもあります。そのエンドポイントを使用してアプリケーションをデバッグし、実行時にSpring Bootによって追加された機能（および追加されていない機能）を確認します。

ソースコードとJavadocを見ると、さらに多くの質問に答えることができます。コードを読むときは、次の経験則を覚えておいてください。

  • *AutoConfiguration と呼ばれるクラスを探し、そのソースを参照してください。 @Conditional* アノテーションに特に注意して、有効にする機能とタイミングを確認してください。コマンドラインまたはシステムプロパティ -Ddebug に --debug を追加して、アプリで行われたすべての自動構成決定のログをコンソールに取得します。アクチュエーターを有効にした実行中のアプリケーションで、同じ情報について conditions エンドポイント（/actuator/conditions または同等のJMX）を調べます。

  • @ConfigurationProperties （ ServerProperties (GitHub) など）であるクラスを探し、そこから利用可能な外部構成オプションを読み取ります。 @ConfigurationProperties アノテーションには、外部プロパティのプレフィックスとして機能する name 属性があります。ServerProperties には prefix="server" があり、その構成プロパティは server.port, server.addressなどです。アクチュエーターを有効にした実行中のアプリケーションで、configprops エンドポイントを参照してください。

  • Binder で bind メソッドの使用を探して、緩和された方法で Environment から明示的に構成値をプルします。多くの場合、接頭辞とともに使用されます。

  • Environmentに直接バインドする @Value アノテーションを探します。

  • 通常 Environmentから解決されたプレースホルダーで評価されるSpEL式に応答して、機能のオンとオフを切り替える @ConditionalOnExpression アノテーションを探します。

1.3. 開始する前に環境またはApplicationContextをカスタマイズする

SpringApplication には、コンテキストまたは環境にカスタマイズを適用するために使用される ApplicationListeners および ApplicationContextInitializers があります。Spring Bootは、META-INF/spring.factoriesから内部的に使用するために、このようなカスタマイズの多くをロードします。追加のカスタマイズを登録する方法は複数あります。

  • プログラムごとに、アプリケーションごとに、SpringApplication で addListeners および addInitializers メソッドを呼び出してから実行します。

  • 宣言的に、アプリケーションごとに、context.initializer.classes または context.listener.classes プロパティを設定することにより。

  • 宣言的に、すべてのアプリケーションについて、META-INF/spring.factories を追加し、すべてのアプリケーションがライブラリとして使用するjarファイルをパッケージ化します。

SpringApplication はいくつかの特別な ApplicationEvents をリスナーに送信し（コンテキストが作成される前でも）、ApplicationContext によって公開されたイベントのリスナーも登録します。完全なリストについては、「Spring Boot機能」セクションの「アプリケーションイベントとリスナー」を参照してください。

EnvironmentPostProcessorを使用して、アプリケーションコンテキストをリフレッシュする前に Environment をカスタマイズすることもできます。次の例に示すように、各実装は META-INF/spring.factoriesに登録する必要があります。

org.springframework.boot.env.EnvironmentPostProcessor=com.example.YourEnvironmentPostProcessor

実装は任意のファイルをロードし、Environmentに追加できます。たとえば、次の例では、クラスパスからYAML構成ファイルをロードします。

public class EnvironmentPostProcessorExample implements EnvironmentPostProcessor {

    private final YamlPropertySourceLoader loader = new YamlPropertySourceLoader();

    @Override
    public void postProcessEnvironment(ConfigurableEnvironment environment, SpringApplication application) {
        Resource path = new ClassPathResource("com/example/myapp/config.yml");
        PropertySource<?> propertySource = loadYaml(path);
        environment.getPropertySources().addLast(propertySource);
    }

    private PropertySource<?> loadYaml(Resource path) {
        if (!path.exists()) {
            throw new IllegalArgumentException("Resource " + path + " does not exist");
        }
        try {
            return this.loader.load("custom-resource", path).get(0);
        }
        catch (IOException ex) {
            throw new IllegalStateException("Failed to load yaml configuration from " + path, ex);
        }
    }

}
Environment は、デフォルトでSpring Bootがロードするすべての通常のプロパティソースで既に準備されています。環境からファイルの場所を取得することが可能です。上記の例では、リストの最後に custom-resource プロパティソースを追加して、他の通常の場所のいずれかで定義されたキーが優先されるようにします。カスタム実装では、別の順序を定義できます。
@SpringBootApplication で @PropertySource を使用することは、Environmentにカスタムリソースをロードする便利な方法のように思えるかもしれませんが、お勧めしません。このようなプロパティソースは、アプリケーションコンテキストがリフレッシュされるまで Environment に追加されません。これは、リフレッシュが開始される前に読み込まれる logging.* や spring.main.* などの特定のプロパティを構成するには遅すぎます。

1.4. ApplicationContext階層を構築する (親またはルートコンテキストの追加)

ApplicationBuilder クラスを使用して、親/子 ApplicationContext 階層を作成できます。詳細については、「Spring Boot機能」セクションの「spring-boot-features.html」を参照してください。

1.5. 非Webアプリケーションを作成する

すべてのSpringアプリケーションがWebアプリケーション（またはWebサービス）である必要はありません。 main メソッドでコードを実行するだけでなく、Springアプリケーションをブートストラップして、使用するインフラストラクチャをセットアップする場合は、Spring Bootの SpringApplication 機能を使用できます。 SpringApplication は、Webアプリケーションが必要かどうかに応じて、ApplicationContext クラスを変更します。これを支援するために最初にできることは、サーバー関連の依存関係（サーブレットAPIなど）をクラスパスから除外することです。それができない場合（たとえば、同じコードベースから2つのアプリケーションを実行する場合）、SpringApplication インスタンスで setWebApplicationType(WebApplicationType.NONE) を明示的に呼び出すか、applicationContextClass プロパティを設定できます（Java APIまたは外部プロパティを使用）。ビジネスロジックとして実行するアプリケーションコードは、CommandLineRunner として実装し、@Bean 定義としてコンテキストにドロップできます。

2. プロパティと構成

このセクションには、プロパティおよび構成設定の設定と読み取り、およびSpring Bootアプリケーションとの相互作用に関するトピックが含まれています。

2.1. ビルド時にプロパティを自動的に展開

プロジェクトのビルド構成でも指定されている一部のプロパティをハードコードするのではなく、既存のビルド構成を代わりに使用して自動的に展開できます。これは、MavenとGradleの両方で可能です。

2.1.1. Mavenを使用した自動プロパティ拡張

リソースフィルタリングを使用して、Mavenプロジェクトのプロパティを自動的に展開できます。 spring-boot-starter-parentを使用する場合、次の例に示すように、@[email protected](英語) プレースホルダーでMavenの「プロジェクトプロパティ」を参照できます。

[email protected](英語)  @
[email protected](英語)  [email protected](英語)
そのようにフィルタリングされるのは本番構成のみです（言い換えると、src/test/resourcesにはフィルタリングは適用されません）。
addResources フラグを有効にすると、spring-boot:run ゴールは src/main/resources をクラスパスに直接追加できます（ホットリロードの目的で）。そうすると、リソースのフィルタリングとこの機能が回避されます。代わりに、exec:java ゴールを使用するか、プラグインの構成をカスタマイズできます。詳細については、プラグインの使用方法のページを参照してください。

スターターの親を使用しない場合は、pom.xmlの <build/> 要素内に次の要素を含める必要があります。

<resources>
    <resource>
        <directory>src/main/resources</directory>
        <filtering>true</filtering>
    </resource>
</resources>

また、<plugins/>内に次の要素を含める必要があります。

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-resources-plugin</artifactId>
    <version>2.7</version>
    <configuration>
        <delimiters>
            <delimiter>@</delimiter>
        </delimiters>
        <useDefaultDelimiters>false</useDefaultDelimiters>
    </configuration>
</plugin>
構成で標準Springプレースホルダー（ ${placeholder}など）を使用する場合、useDefaultDelimiters プロパティは重要です。そのプロパティが falseに設定されていない場合、これらはビルドによって拡張される可能性があります。

2.1.2. Gradleを使用した自動プロパティ拡張

次の例に示すように、Javaプラグインの processResources タスクを構成することにより、Gradleプロジェクトからプロパティを自動的に展開できます。

processResources {
    expand(project.properties)
}

その後、次の例に示すように、プレースホルダーを使用してGradleプロジェクトのプロパティを参照できます。

app.name=${name}
app.description=${description}
Gradleの expand メソッドは、Groovyの SimpleTemplateEngineを使用して、${..} トークンを変換します。 ${..} スタイルは、Spring独自のプロパティプレースホルダーメカニズムと競合します。Springプロパティプレースホルダーと自動展開を併用するには、Springプロパティプレースホルダーを次のようにエスケープします： \${..}。

2.2. SpringApplicationの構成を外部化する

SpringApplication にはBeanプロパティ（主にsetter）があるため、アプリケーションを作成するときにJava APIを使用して動作を変更できます。または、spring.main.*でプロパティを設定することにより、構成を外部化できます。例： application.propertiesでは、次の設定があります。

spring.main.web-application-type=none
spring.main.banner-mode=off

その場合、起動時にSpring Bootバナーは出力されず、アプリケーションは組み込みWebサーバーを起動しません。

外部構成で定義されたプロパティは、ApplicationContextの作成に使用されるソースの顕著な例外を除き、Java APIで指定された値をオーバーライドします。次のアプリケーションを検討してください。

new SpringApplicationBuilder()
    .bannerMode(Banner.Mode.OFF)
    .sources(demo.MyApp.class)
    .run(args);

次に、次の構成を検討します。

spring.main.sources=com.acme.Config,com.acme.ExtraConfig
spring.main.banner-mode=console

実際のアプリケーションは （構成によって上書きされるように）バナーを示し、（次の順序で） ApplicationContext ための3つのソースを使用： demo.MyApp, com.acme.Config、及び com.acme.ExtraConfig。

2.3. アプリケーションの外部プロパティの場所を変更する

デフォルトでは、異なるソースのプロパティが定義済みの順序でSpring Environment に追加されます（正確な順序については、「Spring Boot機能」セクションの「spring-boot-features.html」を参照してください）。

次のシステムプロパティ（または環境変数）を指定して、動作を変更することもできます。

  • spring.config.name （SPRING_CONFIG_NAME）：ファイル名のルートとしてのデフォルトは application です。

  • spring.config.location （SPRING_CONFIG_LOCATION）：ロードするファイル（クラスパスリソースやURLなど）。このドキュメント用に別の Environment プロパティソースが設定されており、システムプロパティ、環境変数、またはコマンドラインでオーバーライドできます。

環境の設定に関係なく、Spring Bootは上記のように application.properties を常にロードします。デフォルトでは、YAMLが使用されている場合、「.yml」拡張子を持つファイルもリストに追加されます。

Spring Bootは、DEBUG レベルでロードされた構成ファイルと、TRACE レベルで見つからなかった候補をログに記録します。

詳細については、 ConfigFileApplicationListener (GitHub) を参照してください。

2.4. 「短い」コマンドライン引数を使用する

コマンドラインで設定プロパティを設定するために、--server.port=9000 の代わりに --port=9000 を使用したい人もいます。次の例に示すように、application.propertiesのプレースホルダーを使用して、この動作を有効にできます。

server.port=${port:8080}
spring-boot-starter-parent POMから継承する場合、maven-resources-plugins のデフォルトのフィルタートークンは ${*} から @ （つまり、${maven.token}ではなく @[email protected](英語) ）に変更され、Springスタイルのプレースホルダーとの競合を防ぎます。 application.properties のMavenフィルタリングを直接有効にしている場合は、デフォルトのフィルタートークンを変更して、他の区切り文字(Apache) を使用することもできます。
この特定のケースでは、ポートバインディングはHerokuやCloud FoundryなどのPaaS環境で機能します。これら2つのプラットフォームでは、PORT 環境変数が自動的に設定され、Springは Environment プロパティの大文字の同義語にバインドできます。

2.5. 外部プロパティにYAMLを使用する

YAMLはJSONのスーパーセットであるため、次の例に示すように、外部プロパティを階層形式で保存するための便利な構文です。

spring:
    application:
        name: cruncher
    datasource:
        driverClassName: com.mysql.jdbc.Driver
        url: jdbc:mysql://localhost/test
server:
    port: 9000

application.yml というファイルを作成し、クラスパスのルートに配置します。次に、snakeyaml を依存関係に追加します（Mavenは org.yaml:snakeyamlを調整します。spring-boot-starterを使用する場合は既に含まれています）。YAMLファイルはJava Map<String,Object> （JSONオブジェクトのように）に解析され、Spring Bootはマップをフラット化して、Javaの Properties ファイルで多くの人が慣れているように、1レベルの深さでピリオドで区切られたキーを持つようにします。

前述のYAMLの例は、次の application.properties ファイルに対応しています。

spring.application.name=cruncher
spring.datasource.driver-class-name=com.mysql.jdbc.Driver
spring.datasource.url=jdbc:mysql://localhost/test
server.port=9000

YAMLの詳細については、「Spring Boot機能」セクションの「spring-boot-features.html」を参照してください。

2.6. アクティブSpringプロファイルを設定する

Spring Environment にはこのためのAPIがありますが、通常はシステムプロパティ（spring.profiles.active）またはOS環境変数（SPRING_PROFILES_ACTIVE）を設定します。また、次のように、-D 引数を使用してアプリケーションを起動できます（メインクラスまたはjarアーカイブの前に配置することを忘れないでください）。

$ java -jar -Dspring.profiles.active=production demo-0.0.1-SNAPSHOT.jar

Spring Bootでは、次の例に示すように、application.propertiesでアクティブなプロファイルを設定することもできます。

spring.profiles.active=production

この方法で設定された値は、SpringApplicationBuilder.profiles() メソッドではなく、システムプロパティまたは環境変数の設定に置き換えられます。後者のJava APIを使用して、デフォルトを変更せずにプロファイルを拡張できます。

詳細については、「Spring Boot機能」セクションの「spring-boot-features.html」を参照してください。

2.7. 環境に応じて構成を変更する

YAMLファイルは、実際には --- 行で区切られた一連のドキュメントであり、各ドキュメントは個別にフラット化されたマップに解析されます。

YAMLドキュメントに spring.profiles キーが含まれている場合、プロファイル値（プロファイルのコンマ区切りリスト）がSpring Environment.acceptsProfiles() メソッドに送られます。これらのプロファイルのいずれかがアクティブな場合、次の例に示すように、そのドキュメントは最終的なマージに含まれます（そうでない場合は含まれません）。

server:
    port: 9000
---

spring:
    profiles: development
server:
    port: 9001

---

spring:
    profiles: production
server:
    port: 0

上記の例では、デフォルトのポートは9000です。ただし、「開発」というSpringプロファイルがアクティブな場合、ポートは9001です。「本番」がアクティブな場合、ポートは0です。

YAMLドキュメントは、検出された順にマージされます。後の値は前の値を上書きします。

プロパティファイルで同じことを行うには、application-${profile}.properties を使用してプロファイル固有の値を指定できます。

2.8. 外部プロパティの組み込みオプションを理解する

Spring Bootは、実行時に application.properties （または .yml ファイルおよびその他の場所）から外部プロパティをアプリケーションにバインドします。1つの場所にすべてのサポートされているプロパティの完全なリストはありません（技術的にはできません）。これは、クラスパス上の追加のjarファイルから提供される可能性があるためです。

アクチュエーター機能を備えた実行中のアプリケーションには、configprops エンドポイントがあり、@ConfigurationPropertiesを介して使用可能なすべてのバインド済みプロパティとバインド可能プロパティが表示されます。

付録には、Spring Bootでサポートされる最も一般的なプロパティのリストを含む application.properties の例が含まれています。最終的なリストは、@ConfigurationProperties および @Value アノテーションのソースコードを検索することと、Binderをときどき使用することから得られます。読み込みプロパティの正確な順序の詳細については、「spring-boot-features.html」を参照してください。

3. 組み込みWebサーバー

各Spring Boot Webアプリケーションには、組み込みWebサーバーが含まれています。この機能は、組み込みサーバーの変更方法や組み込みサーバーの構成方法など、多くの使い方の質問につながります。このセクションでは、これらの質問に回答します。

3.1. 別のWebサーバーを使用する

多くのSpring Bootスターターには、デフォルトの組み込みコンテナーが含まれています。

  • サーブレットスタックアプリケーションの場合、spring-boot-starter-web には spring-boot-starter-tomcatを含めることでTomcatが含まれますが、代わりに spring-boot-starter-jetty または spring-boot-starter-undertow を使用できます。

  • リアクティブスタックアプリケーションの場合、spring-boot-starter-webflux には spring-boot-starter-reactor-nettyを含めることによりReactor Nettyが含まれますが、代わりに spring-boot-starter-tomcat, spring-boot-starter-jettyまたは spring-boot-starter-undertow を使用できます。

別のHTTPサーバーに切り替える場合、必要な依存関係を含めることに加えて、デフォルトの依存関係を除外する必要があります。Spring Bootは、HTTPサーバー用に個別のスターターを提供し、このプロセスを可能な限り簡単にします。

次のMavenの例は、Tomcatを除外し、Spring MVCにJettyを含める方法を示しています。

<properties>
    <servlet-api.version>3.1.0</servlet-api.version>
</properties>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <exclusions>
        <!-- Exclude the Tomcat dependency -->
        <exclusion>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-tomcat</artifactId>
        </exclusion>
    </exclusions>
</dependency>
<!-- Use Jetty instead -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-jetty</artifactId>
</dependency>
Tomcat 9やUndertow 2.0とは異なり、Jetty 9.4はサーブレット4.0をサポートしていないため、サーブレットAPIのバージョンはオーバーライドされています。

次のGradleの例は、Nettyを除外し、Spring WebFluxのUndertowを含める方法を示しています。

configurations {
    // exclude Reactor Netty
    compile.exclude module: 'spring-boot-starter-reactor-netty'
}

dependencies {
    compile 'org.springframework.boot:spring-boot-starter-webflux'
    // Use Undertow instead
    compile 'org.springframework.boot:spring-boot-starter-undertow'
    // ...
}
WebClient クラスを使用するにはspring-boot-starter-reactor-netty が必要なので、別のHTTPサーバーを含める必要がある場合でも、Nettyへの依存関係を維持する必要があります。

3.2. Webサーバーの無効化

クラスパスにWebサーバーの起動に必要なビットが含まれている場合、Spring Bootは自動的に起動します。この動作を無効にするには、次の例に示すように、application.propertiesで WebApplicationType を構成します。

spring.main.web-application-type=none

3.3. HTTPポートを変更する

スタンドアロンアプリケーションでは、メインHTTPポートはデフォルトで 8080 になりますが、server.port で設定できます（たとえば、application.properties またはシステムプロパティとして）。 Environment 値の緩いバインディングのおかげで、SERVER_PORT を使用することもできます（たとえば、OS環境変数として）。

HTTPエンドポイントを完全にオフにしながら WebApplicationContextを作成するには、server.port=-1 を使用します（そうすることはテストに役立つことがあります）。

詳細については、「Spring Boot機能」セクションの「spring-boot-features.html」、または ServerProperties (GitHub) ソースコードを参照してください。

3.4. ランダムな未割り当てのHTTPポートを使用する

（衝突を防ぐためにOSネイティブを使用して）空きポートをスキャンするには、server.port=0を使用します。

3.5. 実行時にHTTPポートを発見する

サーバーが実行されているポートには、ログ出力または ServletWebServerApplicationContext から WebServerを介してアクセスできます。それを取得し、初期化されていることを確認する最善の方法は、タイプ ApplicationListener<ServletWebServerInitializedEvent> の @Bean を追加し、発行時にイベントからコンテナーをプルすることです。

次の例に示すように、@SpringBootTest(webEnvironment=WebEnvironment.RANDOM_PORT) を使用するテストでは、@LocalServerPort アノテーションを使用して、実際のポートをフィールドに挿入することもできます。

@SpringBootTest(webEnvironment=WebEnvironment.RANDOM_PORT)
public class MyWebIntegrationTests {

    @Autowired
    ServletWebServerApplicationContext server;

    @LocalServerPort
    int port;

    // ...

}

@LocalServerPort は @Value("${local.server.port}")のメタアノテーションです。通常のアプリケーションでポートを挿入しようとしないでください。先ほど見たように、値はコンテナーが初期化された後にのみ設定されます。テストとは異なり、アプリケーションコードのコールバックは早期に（値が実際に利用可能になる前に）処理されます。

3.6. HTTPレスポンス圧縮を有効にする

HTTPレスポンス圧縮は、Jetty、Tomcat、Undertowでサポートされています。次のように、application.propertiesで有効にできます。

server.compression.enabled=true

デフォルトでは、圧縮を実行するには、応答の長さが少なくとも2048バイトである必要があります。 server.compression.min-response-size プロパティを設定することにより、この動作を構成できます。

デフォルトでは、コンテンツタイプが次のいずれかである場合にのみ、応答が圧縮されます。

  • text/html

  • text/xml

  • text/plain

  • text/css

  • text/javascript

  • application/javascript

  • application/json

  • application/xml

server.compression.mime-types プロパティを設定することにより、この動作を構成できます。

3.7. SSLを構成する

SSLは、通常 application.properties または application.ymlでさまざまな server.ssl.* プロパティを設定することにより、宣言的に構成できます。次の例は、application.propertiesでのSSLプロパティの設定を示しています。

server.port=8443
server.ssl.key-store=classpath:keystore.jks
server.ssl.key-store-password=secret
server.ssl.key-password=another-secret

サポートされているすべてのプロパティの詳細については、 Ssl (GitHub) を参照してください。

上記の例のような構成を使用すると、アプリケーションはポート8080でプレーンHTTPコネクタをサポートしなくなります。Spring Bootは、application.propertiesを介したHTTPコネクタとHTTPSコネクタの両方の構成をサポートしません。両方が必要な場合は、どちらかをプログラムで設定する必要があります。HTTPコネクターはプログラムで簡単に構成できるため、application.properties を使用してHTTPSを構成することをお勧めします。

3.8. HTTP / 2を構成する

server.http2.enabled 構成プロパティを使用して、Spring BootアプリケーションでHTTP / 2サポートを有効にできます。このサポートは、選択されたWebサーバーとアプリケーション環境に依存します。JDK8では、このプロトコルはすぐにサポートされないためです。

Spring Bootは、HTTP / 2プロトコルのクリアテキストバージョンである h2cをサポートしていません。最初にSSLを構成する必要があります。

3.8.1. Undertowを使用したHTTP / 2

Undertow 1.4.0+の時点では、JDK8で追加の要件なしにHTTP / 2がサポートされています。

3.8.2. Jettyを使用したHTTP / 2

Jetty 9.4.8現在、HTTP / 2も暗号化ライブラリ(英語) でサポートされています。このサポートを有効にするには、アプリケーションに org.eclipse.jetty:jetty-alpn-conscrypt-server と org.eclipse.jetty.http2:http2-serverの2つの追加の依存関係が必要です。

3.8.3. Tomcatを使用したHTTP / 2

Spring BootはデフォルトでTomcat 9.0.xに同梱されており、JDK 9以降を使用している場合はそのままでHTTP / 2をサポートしています。または、libtcnative ライブラリとその依存関係がホストオペレーティングシステムにインストールされている場合、JDK 8でHTTP / 2を使用できます。

ライブラリフォルダーは、JVMライブラリパスに対して使用可能にする必要があります。 -Djava.library.path=/usr/local/opt/tomcat-native/libなどのJVM引数を使用してこれを行うことができます。詳細については、Tomcatの公式ドキュメントを参照してください(Apache) 。

そのネイティブサポートなしでJDK 8でTomcat 9.0.xを起動すると、次のエラーが記録されます。

ERROR 8787 --- [           main] o.a.coyote.http11.Http11NioProtocol      : The upgrade handler [org.apache.coyote.http2.Http2Protocol] for [h2] only supports upgrade via ALPN but has been configured for the ["https-jsse-nio-8443"] connector that does not support ALPN.

このエラーは致命的ではなく、アプリケーションは引き続きHTTP / 1.1 SSLサポートで開始されます。

3.8.4. Reactor Nettyを使用したHTTP / 2

spring-boot-webflux-starter は、デフォルトでReactor Nettyをサーバーとして使用しています。Reactor Nettyは、JDK 9以降のJDKサポートを使用してHTTP / 2用に構成できます。JDK 8環境の場合、または最適な実行時パフォーマンスのために、このサーバーはネイティブライブラリでHTTP / 2もサポートします。それを可能にするには、アプリケーションに追加の依存関係が必要です。

Spring Bootは、すべてのプラットフォームのネイティブライブラリを含む io.netty:netty-tcnative-boringssl-static "uber jar"のバージョンを管理します。開発者は、分類子を使用して必要な依存関係のみをインポートすることを選択できます（ Netty公式ドキュメント(英語) を参照）。

3.9. Webサーバーを構成する

一般に、まず多くの利用可能な構成キーのいずれかを使用することを検討し、application.properties （または application.ymlまたは環境など。「外部プロパティの組み込みオプションを理解する」を参照）に新しいエントリを追加してWebサーバーをカスタマイズします。 server.* 名前空間はここでは非常に便利で、サーバー固有の機能のために server.tomcat.*, server.jetty.* などの名前空間が含まれています。appendix-application-properties.htmlのリストを参照してください。

前のセクションでは、圧縮、SSL、HTTP / 2など、すでに多くの一般的なユースケースについて説明しました。ただし、ユースケースに設定キーが存在しない場合は、 WebServerFactoryCustomizer (Javadoc) を確認する必要があります。このようなコンポーネントを宣言し、選択に関連するサーバーファクトリにアクセスできます。選択したサーバー（Tomcat、Jetty、Reactor、Netty、Undertow）および選択したWebスタック（サーブレットまたはリアクティブ）のバリアントを選択する必要があります。

以下の例は、spring-boot-starter-web （サーブレットスタック）を使用したTomcatの場合です。

@Component
public class MyTomcatWebServerCustomizer
        implements WebServerFactoryCustomizer<TomcatServletWebServerFactory> {

    @Override
    public void customize(TomcatServletWebServerFactory factory) {
        // customize the factory here
    }
}

さらに、Spring Bootは以下を提供します。

サーバーサーブレットスタックリアクティブスタック

Tomcat

TomcatServletWebServerFactory

TomcatReactiveWebServerFactory

Jetty

JettyServletWebServerFactory

JettyReactiveWebServerFactory

Undertow

UndertowServletWebServerFactory

UndertowReactiveWebServerFactory

Reactor

なし

NettyReactiveWebServerFactory

WebServerFactoryにアクセスしたら、多くの場合、カスタマイザーを追加して、コネクタ、サーバーリソース、サーバー自体などの特定の部分を構成できます。すべてサーバー固有のAPIを使用します。

最後の手段として、独自の WebServerFactory コンポーネントを宣言することもできます。これは、Spring Bootによって提供されるコンポーネントをオーバーライドします。この場合、server 名前空間の構成プロパティに依存することはできなくなります。

3.10. サーブレット、フィルター、またはリスナーをアプリケーションに追加する

サーブレットスタックアプリケーション、つまり spring-boot-starter-webを使用する場合、Servlet, Filter, ServletContextListenerと、サーブレットAPIでサポートされる他のリスナーをアプリケーションに追加するには、2つの方法があります。

3.10.1. Spring Beanを使用して、サーブレット、フィルター、またはリスナーを追加する

Spring Beanを使用して Servlet, Filterまたはサーブレット *Listener を追加するには、@Bean 定義を提供する必要があります。これは、構成または依存関係を注入する場合に非常に役立ちます。ただし、アプリケーションライフサイクルの非常に早い段階でコンテナーにインストールする必要があるため、他のBeanの初期化が頻繁に行われないように注意する必要があります。（例： DataSource またはJPA構成に依存させるのは得策ではありません。）初期化ではなく、最初に使用したときに遅延してBeanを初期化することにより、このような制限を回避できます。

Filters および Servletsの場合、基礎となるコンポーネントの代わりに、またはそれに加えて、FilterRegistrationBean または ServletRegistrationBean を追加することにより、マッピングおよび初期化パラメーターを追加することもできます。

フィルター登録で dispatcherType が指定されていない場合、REQUEST が使用されます。これは、サーブレット仕様のデフォルトのディスパッチャタイプと一致します。

他のSpring Beanと同様に、サーブレットフィルターBeanの順序を定義できます。「spring-boot-features.html」セクションを必ず確認してください。

サーブレットまたはフィルターの登録を無効にする

前述のように、Servlet または Filter Beanは、サーブレットコンテナーに自動的に登録されます。特定の Filter または Servlet Beanの登録を無効にするには、次の例に示すように、登録Beanを作成し、無効としてマークします。

@Bean
public FilterRegistrationBean registration(MyFilter filter) {
    FilterRegistrationBean registration = new FilterRegistrationBean(filter);
    registration.setEnabled(false);
    return registration;
}

3.10.2. クラスパススキャンを使用してサーブレット、フィルター、リスナーを追加する

@WebServlet, @WebFilter、および @WebListener アノテーション付きクラスは、@Configuration クラスに @ServletComponentScan アノテーションを付け、登録するコンポーネントを含むパッケージを指定することにより、組み込みサーブレットコンテナーに自動的に登録できます。デフォルトでは、@ServletComponentScan はアノテーション付きクラスのパッケージからスキャンします。

3.11. アクセスログを構成する

Tomcat、Undertow、およびJettyのアクセスログは、それぞれのネームスペースを使用して構成できます。

たとえば、次の設定は、カスタムパターン(Apache) でTomcatへのアクセスを記録します。

server.tomcat.basedir=my-tomcat
server.tomcat.accesslog.enabled=true
server.tomcat.accesslog.pattern=%t %a "%r" %s (%D ms)
ログのデフォルトの場所は、Tomcatベースディレクトリに相対的な logs ディレクトリです。デフォルトでは、logs ディレクトリは一時ディレクトリです。そのため、Tomcatのベースディレクトリを修正するか、ログに絶対パスを使用することができます。上記の例では、ログはアプリケーションの作業ディレクトリに関連する my-tomcat/logs で利用可能です。

Undertowのアクセスロギングは、次の例に示すように、同様の方法で構成できます。

server.undertow.accesslog.enabled=true
server.undertow.accesslog.pattern=%t %a "%r" %s (%D ms)

ログは、アプリケーションの作業ディレクトリに相対的な logs ディレクトリに保存されます。 server.undertow.accesslog.dir プロパティを設定することにより、この場所をカスタマイズできます。

最後に、Jettyのアクセスロギングは次のように構成することもできます。

server.jetty.accesslog.enabled=true
server.jetty.accesslog.filename=/var/log/jetty-access.log

デフォルトでは、ログは System.errにリダイレクトされます。詳細については、Jettyのドキュメント(英語) を参照してください。

3.12. フロントエンドプロキシサーバーの背後で実行する

アプリケーションがプロキシ、ロードバランサー、またはクラウド内で実行されている場合、リクエスト情報（ホスト、ポート、スキームなど）は途中で変更される可能性があります。アプリケーションは 10.10.10.10:8080で実行されている可能性がありますが、HTTPクライアントは example.orgのみを見るはずです。

RFC7239「転送ヘッダー」(英語) は、Forwarded HTTPヘッダーを定義します。プロキシはこのヘッダーを使用して、元のリクエストに関する情報を提供できます。これらのヘッダーを読み取るようにアプリケーションを設定し、リンクを作成してHTTP 302応答、JSONドキュメント、またはHTMLページでクライアントに送信するときにその情報を自動的に使用できます。 X-Forwarded-Host, X-Forwarded-Port, X-Forwarded-Proto, X-Forwarded-Sslや X-Forwarded-Prefixなどの非標準ヘッダーもあります。

プロキシが一般的に使用される X-Forwarded-For および X-Forwarded-Proto ヘッダーを追加する場合、server.forward-headers-strategy を NATIVE に設定するだけでサポートできます。このオプションを使用すると、Webサーバー自体がこの機能をネイティブでサポートします。特定のドキュメントを確認して、特定の動作について学ぶことができます。

これで十分でない場合、Spring FrameworkはForwardedHeaderFilterを提供します。 server.forward-headers-strategy を FRAMEWORKに設定することにより、アプリケーションでサーブレットフィルターとして登録できます。

アプリケーションがCloud FoundryまたはHerokuで実行されている場合、server.forward-headers-strategy プロパティはデフォルトで NATIVEになります。他のすべてのインスタンスでは、デフォルトで NONEになります。

3.12.1. Tomcatのプロキシ設定をカスタマイズする

Tomcatを使用する場合は、次の例に示すように、「転送された」情報を伝達するために使用されるヘッダーの名前を追加で構成できます。

server.tomcat.remote-ip-header=x-your-remote-ip-header
server.tomcat.protocol-header=x-your-protocol-header

Tomcatは、信頼される内部プロキシに一致するデフォルトの正規表現を使用して構成されます。デフォルトでは、10/8, 192.168/16, 169.254/16 および 127/8 のIPアドレスは信頼されています。次の例に示すように、application.propertiesにエントリを追加することにより、バルブの構成をカスタマイズできます。

server.tomcat.internal-proxies=192\\.168\\.\\d{1,3}\\.\\d{1,3}
二重バックスラッシュは、構成にプロパティファイルを使用する場合にのみ必要です。YAMLを使用する場合、単一のバックスラッシュで十分であり、前の例に示されている値と同等の値は 192\.168\.\d{1,3}\.\d{1,3}になります。
internal-proxies を空に設定することにより、すべてのプロキシを信頼できます（ただし、運用環境ではそうしないでください）。

Tomcatの RemoteIpValve の設定を完全に制御するには、自動構成をオフにし（そうするために server.forward-headers-strategy=NONEを設定します）、TomcatServletWebServerFactory Beanに新しいバルブインスタンスを追加します。

3.13. Tomcatで複数のコネクタを有効にする

次の例に示すように、org.apache.catalina.connector.Connector を TomcatServletWebServerFactoryに追加して、HTTPおよびHTTPSコネクタを含む複数のコネクタを許可できます。

@Bean
public ServletWebServerFactory servletContainer() {
    TomcatServletWebServerFactory tomcat = new TomcatServletWebServerFactory();
    tomcat.addAdditionalTomcatConnectors(createSslConnector());
    return tomcat;
}

private Connector createSslConnector() {
    Connector connector = new Connector("org.apache.coyote.http11.Http11NioProtocol");
    Http11NioProtocol protocol = (Http11NioProtocol) connector.getProtocolHandler();
    try {
        File keystore = new ClassPathResource("keystore").getFile();
        File truststore = new ClassPathResource("keystore").getFile();
        connector.setScheme("https");
        connector.setSecure(true);
        connector.setPort(8443);
        protocol.setSSLEnabled(true);
        protocol.setKeystoreFile(keystore.getAbsolutePath());
        protocol.setKeystorePass("changeit");
        protocol.setTruststoreFile(truststore.getAbsolutePath());
        protocol.setTruststorePass("changeit");
        protocol.setKeyAlias("apitester");
        return connector;
    }
    catch (IOException ex) {
        throw new IllegalStateException("can't access keystore: [" + "keystore"
                + "] or truststore: [" + "keystore" + "]", ex);
    }
}

3.14. TomcatのLegacyCookieProcessorを使用する

デフォルトでは、Spring Bootで使用される組み込みTomcatはCookie形式の「バージョン0」をサポートしていないため、次のエラーが表示される場合があります。

java.lang.IllegalArgumentException: An invalid character [32] was present in the Cookie value

可能な限り、後のCookie仕様に準拠した値のみを保存するようにコードを更新することを検討してください。ただし、Cookieの作成方法を変更できない場合は、代わりに LegacyCookieProcessorを使用するようにTomcatを構成できます。 LegacyCookieProcessorに切り替えるには、次の例に示すように、TomcatContextCustomizerを追加する WebServerFactoryCustomizer Beanを使用します。

@Bean
public WebServerFactoryCustomizer<TomcatServletWebServerFactory> cookieProcessorCustomizer() {
    return (factory) -> factory
            .addContextCustomizers((context) -> context.setCookieProcessor(new LegacyCookieProcessor()));
}

3.15. TomcatのMBeanレジストリを有効にする

組み込みTomcatのMBeanレジストリはデフォルトで無効になっています。これにより、Tomcatのメモリフットプリントが最小限に抑えられます。TomcatのMBeanを使用して、たとえば、Micrometerを介してメトリックを公開できるようにする場合は、次の例に示すように、server.tomcat.mbeanregistry.enabled プロパティを使用する必要があります。

server.tomcat.mbeanregistry.enabled=true

3.16. Undertowで複数のリスナーを有効にする

次の例に示すように、UndertowBuilderCustomizer を UndertowServletWebServerFactory に追加し、リスナーを Builderに追加します。

@Bean
public UndertowServletWebServerFactory servletWebServerFactory() {
    UndertowServletWebServerFactory factory = new UndertowServletWebServerFactory();
    factory.addBuilderCustomizers(new UndertowBuilderCustomizer() {

        @Override
        public void customize(Builder builder) {
            builder.addHttpListener(8080, "0.0.0.0");
        }

    });
    return factory;
}

3.17. @ServerEndpointを使用してWebSocketエンドポイントを作成する

埋め込みコンテナーを使用したSpring Bootアプリケーションで @ServerEndpoint を使用する場合は、次の例に示すように、単一の ServerEndpointExporter @Beanを宣言する必要があります。

@Bean
public ServerEndpointExporter serverEndpointExporter() {
    return new ServerEndpointExporter();
}

前の例に示されているBeanは、@ServerEndpoint アノテーション付きBeanを基礎となるWebSocketコンテナーに登録します。スタンドアロンサーブレットコンテナーにデプロイされる場合、このロールはサーブレットコンテナー初期化子によって実行され、ServerEndpointExporter Beanは必要ありません。

4. Spring MVC

Spring Bootには、Spring MVCを含む多くのスターターがあります。一部のスターターには、Spring MVCに直接依存するのではなく、Spring MVCに依存することに注意してください。このセクションでは、Spring MVCおよびSpring Bootに関する一般的な質問に回答します。

4.1. JSON RESTサービスを作成する

次の例に示すように、Spring BootアプリケーションのSpring @RestController は、Jackson2がクラスパス上にある限り、デフォルトでJSON応答をレンダリングする必要があります。

@RestController
public class MyController {

    @RequestMapping("/thing")
    public MyThing thing() {
            return new MyThing();
    }

}

Jackson2が MyThing を直列化できる限り（通常のPOJOまたはGroovyオブジェクトの場合はtrue）、localhost:8080/thing はデフォルトでJSON表現を提供します。ブラウザはXMLを好むAcceptヘッダーを送信する傾向があるため、ブラウザではXML応答が表示されることがあります。

4.2. XML RESTサービスを作成する

クラスパスにJackson XML拡張（jackson-dataformat-xml）がある場合、それを使用してXML応答をレンダリングできます。JSONに使用した前の例は機能します。Jackson XMLレンダラーを使用するには、次の依存関係をプロジェクトに追加します。

<dependency>
    <groupId>com.fasterxml.jackson.dataformat</groupId>
    <artifactId>jackson-dataformat-xml</artifactId>
</dependency>

JacksonのXML拡張機能が利用できず、JAXBが利用可能な場合、次の例に示すように、MyThing に @XmlRootElementとしてアノテーションを付けるという追加要件を使用してXMLをレンダリングできます。

@XmlRootElement
public class MyThing {
    private String name;
    // .. getters and setters
}

JAXBはJava 8.ですぐに使用できます。最新のJava世代を使用している場合は、プロジェクトに次の依存関係を追加します。

<dependency>
    <groupId>org.glassfish.jaxb</groupId>
    <artifactId>jaxb-runtime</artifactId>
</dependency>
サーバーにJSONではなくXMLをレンダリングさせるには、Accept: text/xml ヘッダーを送信する（またはブラウザーを使用する）必要があります。

4.3. Jackson ObjectMapperをカスタマイズする

Spring MVC（クライアントおよびサーバー側）は、HttpMessageConverters を使用して、HTTP交換でのコンテンツ変換をネゴシエートします。Jacksonがクラスパス上にある場合、Jackson2ObjectMapperBuilderが提供するデフォルトのコンバーターをすでに取得しています。そのインスタンスは自動的に構成されます。

ObjectMapper （またはJackson XMLコンバーターの場合は XmlMapper ）インスタンス（デフォルトで作成）には、以下のカスタマイズされたプロパティがあります。

  • MapperFeature.DEFAULT_VIEW_INCLUSION は無効です

  • DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES は無効です

  • SerializationFeature.WRITE_DATES_AS_TIMESTAMPS は無効です

Spring Bootには、この動作を簡単にカスタマイズできるいくつかの機能もあります。

環境を使用して、ObjectMapper および XmlMapper インスタンスを構成できます。Jacksonは、処理のさまざまなアスペクトを構成するために使用できる、単純なオン/オフ機能の広範なスイートを提供します。これらの機能は、環境内のプロパティにマッピングされる6つの列挙（Jackson）で説明されています。

列挙型プロパティ値

com.fasterxml.jackson.databind.DeserializationFeature

spring.jackson.deserialization.<feature_name>

true, false

com.fasterxml.jackson.core.JsonGenerator.Feature

spring.jackson.generator.<feature_name>

true, false

com.fasterxml.jackson.databind.MapperFeature

spring.jackson.mapper.<feature_name>

true, false

com.fasterxml.jackson.core.JsonParser.Feature

spring.jackson.parser.<feature_name>

true, false

com.fasterxml.jackson.databind.SerializationFeature

spring.jackson.serialization.<feature_name>

true, false

com.fasterxml.jackson.annotation.JsonInclude.Include

spring.jackson.default-property-inclusion

always, non_null, non_absent, non_default, non_empty

例：プリティプリントを有効にするには、spring.jackson.serialization.indent_output=trueを設定します。緩いバインディングの使用のおかげで、indent_output のケースは対応する列挙定数のケースと一致する必要がないことに注意してください。これは INDENT_OUTPUTです。

この環境ベースの構成は、自動構成された Jackson2ObjectMapperBuilder Beanに適用され、自動構成された ObjectMapper Beanを含む、ビルダーを使用して作成されたすべてのマッパーに適用されます。

コンテキストの Jackson2ObjectMapperBuilder は、1つ以上の Jackson2ObjectMapperBuilderCustomizer Beanによってカスタマイズできます。このようなカスタマイザーBeanは並べ替えることができ（ブートのカスタマイザーの順序は0）、ブートのカスタマイズの前後に追加のカスタマイズを適用できます。

タイプ com.fasterxml.jackson.databind.Module のBeanはすべて、自動構成された Jackson2ObjectMapperBuilder に自動的に登録され、作成する ObjectMapper インスタンスに適用されます。これにより、アプリケーションに新しい機能を追加するときにカスタムモジュールを提供するグローバルメカニズムが提供されます。

デフォルトの ObjectMapper を完全に置き換える場合は、そのタイプの @Bean を定義して @Primary としてマークするか、ビルダーベースのアプローチを好む場合は Jackson2ObjectMapperBuilder @Beanを定義します。どちらの場合でも、そうすると ObjectMapperのすべての自動構成が無効になることに注意してください。

タイプ MappingJackson2HttpMessageConverterの @Beans を指定すると、MVC構成のデフォルト値が置き換えられます。また、タイプ HttpMessageConverters の便利なBeanが提供されます（デフォルトのMVC構成を使用する場合は常に利用可能です）。デフォルトおよびユーザー拡張のメッセージコンバーターにアクセスするための便利な方法がいくつかあります。

詳細については、「@ResponseBodyレンダリングのカスタマイズ」セクションおよび WebMvcAutoConfiguration (GitHub) ソースコードを参照してください。

4.4. @ResponseBodyレンダリングのカスタマイズ

Springは HttpMessageConverters を使用して @ResponseBody （または @RestControllerからの応答）をレンダリングします。Spring Bootコンテキストに適切なタイプのBeanを追加することにより、追加のコンバーターを提供できます。追加するBeanが、デフォルトで含まれるタイプ（JSON変換の MappingJackson2HttpMessageConverter など）の場合、デフォルト値を置き換えます。タイプ HttpMessageConverters の便利なBeanが提供され、デフォルトのMVC構成を使用する場合は常に利用可能です。デフォルトおよびユーザー拡張のメッセージコンバーターにアクセスするための便利なメソッドがいくつかあります（例：カスタム RestTemplateに手動で挿入したい場合に便利です）。

通常のMVCの使用と同様に、提供する WebMvcConfigurer Beanは、configureMessageConverters メソッドをオーバーライドすることでコンバーターに貢献することもできます。ただし、通常のMVCとは異なり、必要な追加のコンバーターのみを提供できます（Spring Bootは同じメカニズムを使用してデフォルトを提供するため）。最後に、独自の @EnableWebMvc 構成を提供してSpring BootのデフォルトMVC構成をオプトアウトした場合、WebMvcConfigurationSupportから getMessageConverters を使用して完全に制御し、すべてを手動で行うことができます。

詳細については、 WebMvcAutoConfiguration (GitHub) ソースコードを参照してください。

4.5. マルチパートファイルのアップロードの処理

Spring Bootは、ファイルのアップロードをサポートするサーブレット3 javax.servlet.http.Part APIを採用しています。デフォルトでは、Spring Bootは、1回の要求でファイルごとに最大1MB、最大10MBのファイルデータでSpring MVCを構成します。 MultipartProperties クラスで公開されているプロパティを使用して、これらの値、中間データの保存場所（たとえば /tmp ディレクトリ）、およびデータがディスクにフラッシュされるしきい値を上書きできます。例：ファイルを無制限に指定する場合は、spring.servlet.multipart.max-file-size プロパティを -1に設定します。

マルチパートサポートは、Spring MVCコントローラーハンドラーメソッドで、タイプ MultipartFile の @RequestParamアノテーション付きパラメーターとしてマルチパートエンコードされたファイルデータを受信する場合に役立ちます。

詳細については、 MultipartAutoConfiguration (GitHub) ソースを参照してください。

Apache Commons File Uploadのような追加の依存関係を導入するのではなく、コンテナーの組み込みのマルチパートアップロードサポートを使用することをお勧めします。

4.6. Spring MVC DispatcherServletのスイッチを切る

デフォルトでは、すべてのコンテンツはアプリケーションのルート（/）から提供されます。別のパスにマップする場合は、次のように構成できます。

spring.mvc.servlet.path=/acme

追加のサーブレットがある場合、タイプごとに Servlet または ServletRegistrationBean タイプの @Bean を宣言でき、Spring Bootはそれらをコンテナーに透過的に登録します。サーブレットはその方法で登録されるため、DispatcherServlet を呼び出さずに DispatcherServlet のサブコンテキストにマッピングできます。

DispatcherServlet を自分で構成することは珍しいことですが、本当に必要な場合は、DispatcherServletPath タイプの @Bean も提供して、カスタム DispatcherServletのパスを提供する必要があります。

4.7. デフォルトのMVC設定をオフにする

MVC設定を完全に制御する最も簡単な方法は、独自の @Configuration に @EnableWebMvc アノテーションを提供することです。これを行うと、すべてのMVC設定が手元に残ります。

4.8. ViewResolversをカスタマイズする

ViewResolver はSpring MVCのコアコンポーネントであり、@Controller のビュー名を実際の View 実装に変換します。 ViewResolvers は、RESTスタイルのサービスではなく、主にUIアプリケーションで使用されることに注意してください（ View は @ResponseBodyのレンダリングには使用されません）。 ViewResolver の実装には多くの選択肢がありますが、Spring自体は、どの実装を使用すべきかについて意見がありません。一方、Spring Bootは、クラスパスおよびアプリケーションコンテキストで検出した内容に応じて、1つまたは2つをインストールします。 DispatcherServlet は、アプリケーションコンテキストで見つかったすべてのリゾルバーを使用し、結果が得られるまで各リゾルバーを順番に試行します。独自のものを追加する場合、順序とリゾルバーが追加される位置に注意する必要があります。

WebMvcAutoConfiguration は、次の ViewResolvers をコンテキストに追加します。

  • 「defaultViewResolver」という名前の InternalResourceViewResolver。これは、DefaultServlet を使用してレンダリングできる物理リソース（静的リソースとJSPページを使用する場合はそれらを含む）を見つけます。ビュー名にプレフィックスとサフィックスを適用し、サーブレットコンテキストでそのパスを持つ物理リソースを探します（デフォルトは両方とも空ですが、spring.mvc.view.prefix および spring.mvc.view.suffixを介して外部構成からアクセスできます）。同じタイプのBeanを提供することにより、オーバーライドできます。

  • 「beanNameViewResolver」という名前の BeanNameViewResolver。これは、ビューリゾルバーチェーンの有用なメンバーであり、解決される View と同じ名前のBeanをピックアップします。オーバーライドまたは置換する必要はありません。

  • 「viewResolver」という名前の ContentNegotiatingViewResolver は、実際にタイプ View のBeanが存在する場合にのみ追加されます。これは「マスター」リゾルバーであり、他のすべてに委譲し、クライアントから送信された「Accept」HTTPヘッダーに一致するものを見つけようとします。 ContentNegotiatingViewResolverに関する有用なブログ(英語) があり、詳細を学ぶために勉強することができます。また、ソースコードを参照して詳細を調べることもできます。「viewResolver」という名前のBeanを定義することにより、自動構成された ContentNegotiatingViewResolver をオフに切り替えることができます。

  • Thymeleafを使用する場合、「thymeleafViewResolver」という名前の ThymeleafViewResolver もあります。ビュー名をプレフィックスとサフィックスで囲むことにより、リソースを探します。プレフィックスは spring.thymeleaf.prefixで、サフィックスは spring.thymeleaf.suffixです。プレフィックスとサフィックスの値は、デフォルトでそれぞれ「classpath：/templates/」と「.html」になります。同じ名前のBeanを提供することにより、ThymeleafViewResolver をオーバーライドできます。

  • FreeMarkerを使用する場合、「freeMarkerViewResolver」という名前の FreeMarkerViewResolver もあります。ビュー名を接頭辞と接尾辞で囲むことにより、ローダーパス（ spring.freemarker.templateLoaderPath に外部化され、デフォルト値が「classpath：/templates/」である）でリソースを探します。プレフィックスは spring.freemarker.prefixに外部化され、サフィックスは spring.freemarker.suffixに外部化されます。プレフィックスとサフィックスのデフォルト値は、それぞれ空と「.ftlh」です。同じ名前のBeanを提供することにより、FreeMarkerViewResolver をオーバーライドできます。

  • Groovyテンプレートを使用する場合（実際には、groovy-templates がクラスパスにある場合）、「groovyMarkupViewResolver」という名前の GroovyMarkupViewResolver もあります。ビュー名を接頭辞と接尾辞（ spring.groovy.template.prefix および spring.groovy.template.suffixに外部化）で囲むことにより、ローダーパス内のリソースを探します。プレフィックスとサフィックスのデフォルト値はそれぞれ「classpath：/templates/」と「.tpl」です。同じ名前のBeanを提供することにより、GroovyMarkupViewResolver をオーバーライドできます。

  • Mustacheを使用する場合、「mustacheViewResolver」という名前の MustacheViewResolver もあります。ビュー名をプレフィックスとサフィックスで囲むことにより、リソースを探します。プレフィックスは spring.mustache.prefixで、サフィックスは spring.mustache.suffixです。接頭辞と接尾辞の値は、デフォルトでそれぞれ「classpath：/templates/」と「.mustache」になります。同じ名前のBeanを提供することにより、MustacheViewResolver をオーバーライドできます。

詳細については、次のセクションを参照してください。

5. Spring Securityを使用したテスト

Spring Securityは、特定のユーザーとしてテストを実行するためのサポートを提供します。例：以下のスニペットのテストは、ADMIN ロールを持つ認証済みユーザーで実行されます。

@Test
@WithMockUser(roles="ADMIN")
public void requestProtectedUrlWithUser() throws Exception {
    mvc
        .perform(get("/"))
        ...
}

Spring SecurityはSpring MVC Testとの包括的な統合を提供し、これは @WebMvcTest スライスと MockMvcを使用してコントローラーをテストするときにも使用できます。

Spring Securityのテストサポートの詳細については、Spring Securityのリファレンスドキュメントを参照してください。

6. Jersey

6.1. Spring Securityを使用したJerseyエンドポイントの保護

Spring Securityは、Spring MVCベースのWebアプリケーションを保護するために使用できるのとほぼ同じ方法で、JerseyベースのWebアプリケーションを保護するために使用できます。ただし、JerseyでSpring Securityのメソッドレベルセキュリティを使用する場合は、sendError(int)ではなく setStatus(int) を使用するようにJerseyを構成する必要があります。これにより、Spring Securityがクライアントに認証または認可の失敗を報告する機会を得る前に、Jerseyが応答をコミットすることを防ぎます。

次の例に示すように、アプリケーションの ResourceConfig Beanで jersey.config.server.response.setStatusOverSendError プロパティを true に設定する必要があります。

@Component
public class JerseyConfig extends ResourceConfig {

    public JerseyConfig() {
        register(Endpoint.class);
        setProperties(Collections.singletonMap("jersey.config.server.response.setStatusOverSendError", true));
    }

}

6.2. 別のWeb フレームワークと一緒にJerseyを使用する

Spring MVCなどの別のWebフレームワークとともにJerseyを使用するには、他のフレームワークが処理できない要求を処理できるように構成する必要があります。最初に、filterの値で spring.jersey.type アプリケーションプロパティを設定することにより、サーブレットではなくフィルタを使用するようにJerseyを設定します。次に、次の例に示すように、結果として404になるリクエストを転送するように ResourceConfig を構成します。

@Component
public class JerseyConfig extends ResourceConfig {

    public JerseyConfig() {
        register(Endpoint.class);
        property(ServletProperties.FILTER_FORWARD_ON_404, true);
    }

}

7. HTTP クライアント

Spring Bootは、HTTPクライアントで動作する多くのスターターを提供します。このセクションでは、それらの使用に関する質問に回答します。

7.1. プロキシを使用するためのRestTemplateの構成

spring-boot-features.htmlに従って、RestTemplateCustomizer と RestTemplateBuilder を使用して、カスタマイズされた RestTemplateを作成できます。これは、プロキシを使用するように構成された RestTemplate を作成するための推奨アプローチです。

プロキシ構成の正確な詳細は、使用されている基礎となるクライアント要求ファクトリーによって異なります。次の例では、192.168.0.5を除くすべてのホストにプロキシを使用する HttpClient で HttpComponentsClientRequestFactory を構成します。

static class ProxyCustomizer implements RestTemplateCustomizer {

    @Override
    public void customize(RestTemplate restTemplate) {
        HttpHost proxy = new HttpHost("proxy.example.com");
        HttpClient httpClient = HttpClientBuilder.create().setRoutePlanner(new DefaultProxyRoutePlanner(proxy) {

            @Override
            public HttpHost determineProxy(HttpHost target, HttpRequest request, HttpContext context)
                    throws HttpException {
                if (target.getHostName().equals("192.168.0.5")) {
                    return null;
                }
                return super.determineProxy(target, request, context);
            }

        }).build();
        restTemplate.setRequestFactory(new HttpComponentsClientHttpRequestFactory(httpClient));
    }

}

7.2. Reactor NettyベースのWebClientが使用するTcpClientを構成する

Reactor Nettyがクラスパスにある場合、Reactor Nettyベースの WebClient が自動構成されます。クライアントのネットワーク接続の処理をカスタマイズするには、ClientHttpConnector Beanを提供します。次の例では、60秒の接続タイムアウトを構成し、ReadTimeoutHandlerを追加します。

@Bean
ClientHttpConnector clientHttpConnector(ReactorResourceFactory resourceFactory) {
    TcpClient tcpClient = TcpClient.create(resourceFactory.getConnectionProvider())
            .runOn(resourceFactory.getLoopResources()).option(ChannelOption.CONNECT_TIMEOUT_MILLIS, 60000)
            .doOnConnected((connection) -> connection.addHandlerLast(new ReadTimeoutHandler(60)));
    return new ReactorClientHttpConnector(HttpClient.from(tcpClient));
}
接続プロバイダーおよびイベントループリソースに ReactorResourceFactory を使用していることに注意してください。これにより、リクエストを受信するサーバーとリクエストを行うクライアントのリソースを効率的に共有できます。

8. ロギング

Spring Bootには、Spring Frameworkの spring-jcl モジュールによって通常提供されるCommons Logging APIを除き、必須のロギング依存関係はありません。Logback(英語) を使用するには、それと spring-jcl をクラスパスに含める必要があります。それを行う最も簡単な方法は、すべて spring-boot-starter-loggingに依存するスターターを使用することです。Webアプリケーションの場合、spring-boot-starter-webのみが必要です。これは、ロギングスターターに依存するためです。Mavenを使用する場合、次の依存関係によりロギングが追加されます。

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

Spring Bootには、クラスパスのコンテンツに基づいてロギングを構成しようとする LoggingSystem 抽象化があります。Logbackが利用可能な場合、それが最初の選択肢です。

ロギングに対して行う必要がある唯一の変更がさまざまなロガーのレベルの設定である場合、次の例に示すように、「logging.level」プレフィックスを使用して application.properties で設定できます。

logging.level.org.springframework.web=DEBUG
logging.level.org.hibernate=ERROR

「logging.file.name」を使用して、（コンソールに加えて）ログを書き込むファイルの場所を設定することもできます。

ロギングシステムのよりきめ細かい設定を構成するには、対象の LoggingSystem でサポートされているネイティブ構成形式を使用する必要があります。デフォルトでは、Spring Bootはシステムのデフォルトの場所（Logbackの場合は classpath:logback.xml など）からネイティブ構成を選択しますが、logging.config プロパティを使用して構成ファイルの場所を設定できます。

8.1. ロギング用にLogbackを構成する

application.propertiesで達成できるもの以外にlogbackにカスタマイズを適用する必要がある場合は、標準のlogback構成ファイルを追加する必要があります。logbackが検索できるように、logback.xml ファイルをクラスパスのルートに追加できます。Spring Boot Logback拡張を使用する場合は、logback-spring.xml も使用できます。

Logbackのドキュメントには、構成を詳細にカバーする専用セクションがあります(英語) 。

Spring Bootは、独自の構成から included である多数のlogback構成を提供します。これらのインクルードは、特定の一般的なSpring Boot規則を再適用できるように設計されています。

以下のファイルが org/springframework/boot/logging/logback/で提供されています。

  • defaults.xml - 変換ルール、パターンプロパティ、および一般的なロガー構成を提供します。

  • console-appender.xml - CONSOLE_LOG_PATTERNを使用して ConsoleAppender を追加します。

  • file-appender.xml - 適切な設定で FILE_LOG_PATTERN および ROLLING_FILE_NAME_PATTERN を使用して RollingFileAppender を追加します。

さらに、以前のバージョンのSpring Bootとの互換性のために、レガシー base.xml ファイルが提供されています。

典型的なカスタム logback.xml ファイルは次のようになります。

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <include resource="org/springframework/boot/logging/logback/defaults.xml"/>
    <include resource="org/springframework/boot/logging/logback/console-appender.xml" />
    <root level="INFO">
        <appender-ref ref="CONSOLE" />
    </root>
    <logger name="org.springframework.web" level="DEBUG"/>
</configuration>

logback構成ファイルは、LoggingSystem が作成するシステムプロパティを利用することもできます。

  • ${PID} : 現在のプロセスID。

  • ${LOG_FILE} : logging.file.name がブートの外部構成で設定されたかどうか。

  • ${LOG_PATH} : logging.file.path （ログファイルが存在するディレクトリを表す）がブートの外部設定で設定されたかどうか。

  • ${LOG_EXCEPTION_CONVERSION_WORD} : logging.exception-conversion-word がブートの外部構成で設定されたかどうか。

  • ${ROLLING_FILE_NAME_PATTERN} : logging.pattern.rolling-file-name がブートの外部構成で設定されたかどうか。

また、Spring Bootは、カスタムLogbackコンバーターを使用して、コンソール上に（ログファイルではなく）素敵なANSIカラーターミナル出力を提供します。例については、defaults.xml 構成の CONSOLE_LOG_PATTERN を参照してください。

Groovyがクラスパス上にある場合、logback.groovy でLogbackも構成できるはずです。存在する場合、この設定が優先されます。

Spring拡張は、Groovy構成ではサポートされていません。 logback-spring.groovy ファイルは検出されません。

8.1.1. ファイルのみの出力用にLogbackを構成する

コンソールロギングを無効にし、出力のみをファイルに書き込む場合は、次の例に示すように、console-appender.xmlではなく file-appender.xml をインポートするカスタム logback-spring.xml が必要です。

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <include resource="org/springframework/boot/logging/logback/defaults.xml" />
    <property name="LOG_FILE" value="${LOG_FILE:-${LOG_PATH:-${LOG_TEMP:-${java.io.tmpdir:-/tmp}}/}spring.log}"/>
    <include resource="org/springframework/boot/logging/logback/file-appender.xml" />
    <root level="INFO">
        <appender-ref ref="FILE" />
    </root>
</configuration>

次の例に示すように、logging.file.name を application.propertiesに追加する必要もあります。

logging.file.name=myapplication.log

8.2. ロギング用にLog4jを構成する

Spring Bootは、クラスパス上にある場合、ロギング構成のLog4j 2(Apache) をサポートします。依存関係のアセンブルにスターターを使用する場合は、Logbackを除外してから、代わりにlog4j 2を含める必要があります。スターターを使用しない場合は、Log4j 2に加えて（少なくとも） spring-jcl を提供する必要があります。

最も単純なパスは、除外を使用してジグリングを必要とする場合でも、おそらくスターターを経由することです。次の例は、Mavenでスターターをセットアップする方法を示しています。

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter</artifactId>
    <exclusions>
        <exclusion>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-logging</artifactId>
        </exclusion>
    </exclusions>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-log4j2</artifactId>
</dependency>

また、次の例は、Gradleでスターターをセットアップする1つの方法を示しています。

dependencies {
    compile 'org.springframework.boot:spring-boot-starter-web'
    compile 'org.springframework.boot:spring-boot-starter-log4j2'
}

configurations {
    all {
        exclude group: 'org.springframework.boot', module: 'spring-boot-starter-logging'
    }
}
Log4jスターターは、共通のロギング要件（Tomcatで java.util.logging を使用するがLog4j 2を使用して出力を構成するなど）の依存関係を収集します。
java.util.logging を使用して実行されるデバッグロギングがLog4j 2にルーティングされるようにするには、java.util.logging.manager システムプロパティを org.apache.logging.log4j.jul.LogManagerに設定して、JDKロギングアダプター(Apache) を構成します。

8.2.1. YAMLまたはJSONを使用してLog4j 2を構成する

デフォルトのXML構成形式に加えて、Log4j 2はYAMLおよびJSON構成ファイルもサポートしています。別の構成ファイル形式を使用するようにLog4j 2を構成するには、次の例に示すように、適切な依存関係をクラスパスに追加し、選択したファイル形式に合わせて構成ファイルに名前を付けます。

フォーマット依存関係ファイル名

YAML

com.fasterxml.jackson.core:jackson-databind + com.fasterxml.jackson.dataformat:jackson-dataformat-yaml

log4j2.yaml + log4j2.yml

JSON

com.fasterxml.jackson.core:jackson-databind

log4j2.json + log4j2.jsn

9. データアクセス

Spring Bootには、データソースを操作するための多くのスターターが含まれています。このセクションでは、そうすることに関する質問に回答します。

9.1. カスタムDataSourceを構成する

独自の DataSourceを構成するには、構成でそのタイプの @Bean を定義します。Spring Bootは、データベースの初期化を含め、DataSource が必要な場所で再利用します。一部の設定を外部化する必要がある場合は、DataSource を環境にバインドできます（「spring-boot-features.html」を参照）。

次の例は、Beanでデータソースを定義する方法を示しています。

@Bean
@ConfigurationProperties(prefix="app.datasource")
public DataSource dataSource() {
    return new FancyDataSource();
}

次の例は、プロパティを設定してデータソースを定義する方法を示しています。

app.datasource.url=jdbc:h2:mem:mydb
app.datasource.username=sa
app.datasource.pool-size=30

FancyDataSource にURL、ユーザー名、およびプールサイズの通常のJavaBeanプロパティがあると仮定すると、これらの設定は、DataSource が他のコンポーネントで使用可能になる前に自動的にバインドされます。定期的なデータベースの初期化も行われます （したがって、spring.datasource.* の関連サブセットをカスタム構成で引き続き使用できます）。

Spring Bootは、DataSourceBuilderと呼ばれるユーティリティビルダークラスも提供します。これは、標準データソースの1つを作成するために使用できます（クラスパス上にある場合）。ビルダーは、クラスパスで利用可能なものに基づいて、使用するものを検出できます。また、JDBC URLに基づいてドライバーを自動検出します。

次の例は、DataSourceBuilderを使用してデータソースを作成する方法を示しています。

@Bean
@ConfigurationProperties("app.datasource")
public DataSource dataSource() {
    return DataSourceBuilder.create().build();
}

その DataSourceでアプリを実行するために必要なのは、接続情報だけです。プール固有の設定も提供できます。詳細については、実行時に使用される実装を確認してください。

次の例は、プロパティを設定してJDBCデータソースを定義する方法を示しています。

app.datasource.url=jdbc:mysql://localhost/test
app.datasource.username=dbuser
app.datasource.password=dbpass
app.datasource.pool-size=30

しかし、落とし穴があります。接続プールの実際の種類が公開されていないため、カスタム DataSource のメタデータにキーが生成されず、( DataSource インターフェースはプロパティを公開しないため) IDEで補完機能を使用できません。また、クラスパスにHikariがある場合、Hikariには url プロパティがない (ただし、jdbcUrl プロパティはある) ため、この基本セットアップは機能しません。その場合は、設定を次のように書き直す必要があります。

app.datasource.jdbc-url=jdbc:mysql://localhost/test
app.datasource.username=dbuser
app.datasource.password=dbpass
app.datasource.maximum-pool-size=30

接続プールが DataSourceではなく専用の実装を使用して返すように強制することで、これを修正できます。実行時に実装を変更することはできませんが、オプションのリストは明示的になります。

次の例は、DataSourceBuilderで HikariDataSource を作成する方法を示しています。

@Bean
@ConfigurationProperties("app.datasource")
public HikariDataSource dataSource() {
    return DataSourceBuilder.create().type(HikariDataSource.class).build();
}

DataSourceProperties の機能を活用することで、つまりURLが提供されていない場合に適切なユーザー名とパスワードをデフォルトの組み込みデータベースに提供することで、さらに先に進むこともできます。 DataSourceProperties オブジェクトの状態から DataSourceBuilder を簡単に初期化できるため、Spring Bootが自動的に作成するDataSourceを挿入することもできます。ただし、その場合、構成は2つのネームスペースに分割されます： url, username, password, type、および spring.datasource 上の driver と残りはカスタムネームスペース（app.datasource）にあります。これを回避するには、次の例に示すように、カスタム名前空間でカスタム DataSourceProperties を再定義できます。

@Bean
@Primary
@ConfigurationProperties("app.datasource")
public DataSourceProperties dataSourceProperties() {
    return new DataSourceProperties();
}

@Bean
@ConfigurationProperties("app.datasource.configuration")
public HikariDataSource dataSource(DataSourceProperties properties) {
    return properties.initializeDataSourceBuilder().type(HikariDataSource.class).build();
}

この設定により、デフォルトでSpring Bootが行うことと同期されますが、専用の接続プールが（コードで）選択され、その設定が app.datasource.configuration サブ名前空間で公開される点が異なります。 DataSourceProperties が url / jdbcUrl 変換を処理するため、次のように構成できます。

app.datasource.url=jdbc:mysql://localhost/test
app.datasource.username=dbuser
app.datasource.password=dbpass
app.datasource.configuration.maximum-pool-size=30
Spring Bootは、Hikari固有の設定を spring.datasource.hikariに公開します。この例では複数のデータソース実装をサポートしていないため、この例ではより一般的な configuration サブ名前空間を使用します。
カスタム構成ではHikariを選択するため、app.datasource.type は効果がありません。実際には、ビルダーはそこに設定する可能性のある値で初期化され、.type()の呼び出しによってオーバーライドされます。

詳細については、「Spring Boot機能」セクションの「spring-boot-features.html」および DataSourceAutoConfiguration (GitHub) クラスを参照してください。

9.2. 2つのDataSourcesを構成する

複数のデータソースを構成する必要がある場合は、前のセクションで説明したものと同じトリックを適用できます。ただし、DataSource インスタンスの1つを @Primaryとしてマークする必要があります。今後のさまざまな自動構成では、タイプごとに1つを取得できると予想されるためです。

独自の DataSourceを作成すると、自動構成はバックオフします。次の例では、自動構成がプライマリデータソースで提供するものとまったく同じ機能セットを提供します。

@Bean
@Primary
@ConfigurationProperties("app.datasource.first")
public DataSourceProperties firstDataSourceProperties() {
    return new DataSourceProperties();
}

@Bean
@Primary
@ConfigurationProperties("app.datasource.first.configuration")
public HikariDataSource firstDataSource() {
    return firstDataSourceProperties().initializeDataSourceBuilder().type(HikariDataSource.class).build();
}

@Bean
@ConfigurationProperties("app.datasource.second")
public BasicDataSource secondDataSource() {
    return DataSourceBuilder.create().type(BasicDataSource.class).build();
}
データベース初期化機能がコピーを使用するように、firstDataSourceProperties に @Primary のフラグを立てる必要があります（初期化を使用する場合）。

両方のデータソースは、高度なカスタマイズにも対応しています。たとえば、次のように構成できます。

app.datasource.first.url=jdbc:mysql://localhost/first
app.datasource.first.username=dbuser
app.datasource.first.password=dbpass
app.datasource.first.configuration.maximum-pool-size=30

app.datasource.second.url=jdbc:mysql://localhost/second
app.datasource.second.username=dbuser
app.datasource.second.password=dbpass
app.datasource.second.max-total=30

次の例に示すように、セカンダリ DataSource にも同じ概念を適用できます。

@Bean
@Primary
@ConfigurationProperties("app.datasource.first")
public DataSourceProperties firstDataSourceProperties() {
    return new DataSourceProperties();
}

@Bean
@Primary
@ConfigurationProperties("app.datasource.first.configuration")
public HikariDataSource firstDataSource() {
    return firstDataSourceProperties().initializeDataSourceBuilder().type(HikariDataSource.class).build();
}

@Bean
@ConfigurationProperties("app.datasource.second")
public DataSourceProperties secondDataSourceProperties() {
    return new DataSourceProperties();
}

@Bean
@ConfigurationProperties("app.datasource.second.configuration")
public BasicDataSource secondDataSource() {
    return secondDataSourceProperties().initializeDataSourceBuilder().type(BasicDataSource.class).build();
}

前の例では、Spring Bootが自動構成で使用するのと同じロジックを使用して、カスタム名前空間に2つのデータソースを構成します。各 configuration サブ名前空間は、選択した実装に基づいて高度な設定を提供することに注意してください。

9.3. Spring Dataリポジトリを使用する

Spring Dataは、さまざまなフレーバーの @Repository インターフェースの実装を作成できます。 @Repositories が @EnableAutoConfiguration クラスの同じパッケージ（またはサブパッケージ）に含まれている限り、Spring Bootはそれらすべてを処理します。

多くのアプリケーションで必要なのは、クラスパスに正しいSpring Data依存関係を置くことだけです。JPAには spring-boot-starter-data-jpa、Mongodbには spring-boot-starter-data-mongodb などがあります。開始するには、@Entity オブジェクトを処理するリポジトリインターフェースをいくつか作成します。

Spring Bootは、検出した @EnableAutoConfiguration に基づいて、@Repository 定義の場所を推測しようとします。さらに制御するには、@EnableJpaRepositories アノテーション（Spring Data JPAから）を使用します。

Spring Dataの詳細については、Spring Dataプロジェクトページを参照してください。

9.4. Spring構成から@Entity定義を分離する

Spring Bootは、検出した @EnableAutoConfiguration に基づいて、@Entity 定義の場所を推測しようとします。さらに制御するには、次の例に示すように、@EntityScan アノテーションを使用できます。

@Configuration(proxyBeanMethods = false)
@EnableAutoConfiguration
@EntityScan(basePackageClasses=City.class)
public class Application {

    //...

}

9.5. JPAプロパティの構成

Spring Data JPAは、ベンダーに依存しないいくつかの構成オプション（SQLロギングのオプションなど）をすでに提供しており、Spring BootはそれらのオプションとHibernateのいくつかを外部構成プロパティとして公開しています。それらの一部はコンテキストに従って自動的に検出されるため、設定する必要はありません。

spring.jpa.hibernate.ddl-auto は、ランタイム条件に応じて異なるデフォルト値を持っているため、特別なケースです。組み込みデータベースが使用され、スキーママネージャー（LiquibaseやFlywayなど）が DataSourceを処理していない場合、デフォルトは create-dropになります。他のすべての場合、デフォルトは noneです。

使用するダイアレクトはJPAプロバイダーによって検出されます。ダイアレクトを自分で設定する場合は、spring.jpa.database-platform プロパティを設定します。

設定する最も一般的なオプションを次の例に示します。

spring.jpa.hibernate.naming.physical-strategy=com.example.MyPhysicalNamingStrategy
spring.jpa.show-sql=true

また、spring.jpa.properties.* のすべてのプロパティは、ローカル EntityManagerFactory が作成されるときに、通常のJPAプロパティとして（プレフィックスが削除された状態で）渡されます。

spring.jpa.properties.* で定義された名前が、JPAプロバイダーが期待する名前と正確に一致することを確認する必要があります。Spring Bootは、これらのエントリに対して緩いバインディングを試みません。

例：Hibernateのバッチサイズを設定する場合は、spring.jpa.properties.hibernate.jdbc.batch_sizeを使用する必要があります。 batchSize や batch-sizeなどの他のフォームを使用する場合、Hibernateは設定を適用しません。

Hibernateプロパティに高度なカスタマイズを適用する必要がある場合は、EntityManagerFactoryを作成する前に呼び出される HibernatePropertiesCustomizer Beanを登録することを検討してください。これは、自動構成によって適用されるものよりも優先されます。

9.6. Hibernate命名戦略の構成

Hibernateは、2つの異なる命名戦略(英語) を使用して、オブジェクトモデルから対応するデータベース名に名前をマッピングします。 spring.jpa.hibernate.naming.physical-strategy プロパティと spring.jpa.hibernate.naming.implicit-strategy プロパティをそれぞれ設定することにより、物理的および暗黙的な戦略実装の完全修飾クラス名を構成できます。または、ImplicitNamingStrategy または PhysicalNamingStrategy Beanがアプリケーションコンテキストで使用可能な場合、Hibernateはそれらを使用するように自動的に構成されます。

デフォルトでは、Spring Bootは SpringPhysicalNamingStrategyを使用して物理命名戦略を構成します。この実装は、Hibernate 4と同じテーブル構造を提供します。すべてのドットはアンダースコアに置き換えられ、ラクダのケーシングもアンダースコアに置き換えられます。デフォルトでは、すべてのテーブル名は小文字で生成されますが、スキーマで必要な場合はそのフラグをオーバーライドできます。

例： TelephoneNumber エンティティは telephone_number テーブルにマッピングされます。

代わりにHibernate 5のデフォルトを使用する場合は、次のプロパティを設定します。

spring.jpa.hibernate.naming.physical-strategy=org.hibernate.boot.model.naming.PhysicalNamingStrategyStandardImpl

または、次のBeanを構成できます。

@Bean
public PhysicalNamingStrategy physicalNamingStrategy() {
    return new PhysicalNamingStrategyStandardImpl();
}

詳細については、 HibernateJpaAutoConfiguration (GitHub) および JpaBaseConfiguration (GitHub) を参照してください。

9.7. Hibernate 2次キャッシュを構成する

Hibernate 2次キャッシュ(英語) は、さまざまなキャッシュプロバイダーに対して構成できます。キャッシュプロバイダーを再度検索するようにHibernateを構成するのではなく、可能な場合はコンテキストで利用可能なものを提供することをお勧めします。

JCacheを使用している場合、これは非常に簡単です。最初に、org.hibernate:hibernate-jcache がクラスパスで利用可能であることを確認してください。次に、次の例に示すように、HibernatePropertiesCustomizer Beanを追加します。

@Configuration(proxyBeanMethods = false)
public class HibernateSecondLevelCacheExample {

    @Bean
    public HibernatePropertiesCustomizer hibernateSecondLevelCacheCustomizer(JCacheCacheManager cacheManager) {
        return (properties) -> properties.put(ConfigSettings.CACHE_MANAGER, cacheManager.getCacheManager());
    }

}

このカスタマイザーは、アプリケーションが使用するものと同じ CacheManager を使用するようにHibernateを構成します。別の CacheManager インスタンスを使用することもできます。詳細については、Hibernateユーザーガイドを参照してください(英語) 。

9.8. Hibernateコンポーネントでの依存性注入の使用

デフォルトでは、Spring Bootは BeanFactory を使用する BeanContainer 実装を登録して、コンバーターとエンティティーリスナーが通常の依存性注入を使用できるようにします。

hibernate.resource.beans.container プロパティを削除または変更する HibernatePropertiesCustomizer を登録することにより、この動作を無効化または調整できます。

9.9. カスタムEntityManagerFactoryを使用する

EntityManagerFactoryの構成を完全に制御するには、「entityManagerFactory」という名前の @Bean を追加する必要があります。Spring Boot自動構成は、そのタイプのBeanが存在する場合、エンティティマネージャーをオフにします。

9.10. EntityManagersを2つ使用する

デフォルトの EntityManagerFactory が正常に機能する場合でも、新しいものを定義する必要があります。そうでない場合、そのタイプの2番目のBeanが存在すると、デフォルトがオフになります。簡単にするために、Spring Bootが提供する便利な EntityManagerBuilder を使用できます。または、次の例に示すように、Spring ORMから直接 LocalContainerEntityManagerFactoryBean のみを実行できます。

// add two data sources configured as above

@Bean
public LocalContainerEntityManagerFactoryBean customerEntityManagerFactory(
        EntityManagerFactoryBuilder builder) {
    return builder
            .dataSource(customerDataSource())
            .packages(Customer.class)
            .persistenceUnit("customers")
            .build();
}

@Bean
public LocalContainerEntityManagerFactoryBean orderEntityManagerFactory(
        EntityManagerFactoryBuilder builder) {
    return builder
            .dataSource(orderDataSource())
            .packages(Order.class)
            .persistenceUnit("orders")
            .build();
}
LocalContainerEntityManagerFactoryBean 用のBeanを自分で作成すると、自動構成された LocalContainerEntityManagerFactoryBean の作成中に適用されたカスタマイズは失われます。例：Hibernateの場合、spring.jpa.hibernate プレフィックスのプロパティは LocalContainerEntityManagerFactoryBeanに自動的に適用されません。命名戦略やDDLモードなどを設定するためにこれらのプロパティに依存していた場合、LocalContainerEntityManagerFactoryBean Beanを作成するときに明示的に設定する必要があります。一方、spring.jpa.propertiesを介して指定された自動構成 EntityManagerFactoryBuilderに適用されるプロパティは、自動構成 EntityManagerFactoryBuilder を使用して LocalContainerEntityManagerFactoryBean Beanを構築する場合に自動的に適用されます。

上記の構成は、ほとんど単独で機能します。図を完成させるには、2つの EntityManagers の TransactionManagers も構成する必要があります。それらのいずれかを @Primaryとしてマークすると、Spring Bootのデフォルトの JpaTransactionManager によってピックアップされる可能性があります。もう1つは、新しいインスタンスに明示的に挿入する必要があります。または、両方にまたがるJTAトランザクションマネージャーを使用できる場合があります。

Spring Dataを使用する場合、次の例に示すように、それに応じて @EnableJpaRepositories を構成する必要があります。

@Configuration(proxyBeanMethods = false)
@EnableJpaRepositories(basePackageClasses = Customer.class,
        entityManagerFactoryRef = "customerEntityManagerFactory")
public class CustomerConfiguration {
    ...
}

@Configuration(proxyBeanMethods = false)
@EnableJpaRepositories(basePackageClasses = Order.class,
        entityManagerFactoryRef = "orderEntityManagerFactory")
public class OrderConfiguration {
    ...
}

9.11. 従来の persistence.xml ファイルを使用する

Spring Bootは、デフォルトでは META-INF/persistence.xml を検索または使用しません。従来の persistence.xmlを使用する場合は、タイプ LocalEntityManagerFactoryBean の独自の @Bean （「entityManagerFactory」のIDを使用）を定義し、そこに永続性ユニット名を設定する必要があります。

デフォルト設定については、 JpaBaseConfiguration (GitHub) を参照してください。

9.12. Spring Data JPAとMongoリポジトリを使用する

Spring Data JPAとSpring Data Mongoはどちらも Repository 実装を自動的に作成できます。両方がクラスパスに存在する場合は、Spring Bootに作成するリポジトリを指示するために、追加の構成が必要になる場合があります。最も明示的な方法は、標準のSpring Data @EnableJpaRepositories および @EnableMongoRepositories アノテーションを使用して、Repository インターフェースの場所を提供することです。

また、外部構成で自動構成リポジトリのオンとオフを切り替えるために使用できるフラグ（spring.data.*.repositories.enabled および spring.data.*.repositories.type）もあります。これは、たとえば、Mongoリポジトリをオフにし、自動構成された MongoTemplateを使用したい場合に便利です。

他の自動構成されたSpring Dataリポジトリタイプ（Elasticsearch、Solrなど）にも同じ障害と同じ機能が存在します。使用するには、アノテーションの名前とフラグを適宜変更します。

9.13. Spring DataのWebサポートのカスタマイズ

Spring Dataは、WebアプリケーションでSpring Dataリポジトリの使用を簡素化するWebサポートを提供します。Spring Bootは、構成をカスタマイズするために spring.data.web 名前空間にプロパティを提供します。Spring Data RESTを使用している場合、代わりに spring.data.rest 名前空間のプロパティを使用する必要があることに注意してください。

9.14. Spring DataリポジトリをRESTエンドポイントとして公開する

Spring MVCがアプリケーションで有効になっている場合、Spring Data RESTは Repository 実装をRESTエンドポイントとして公開できます。

Spring Bootは、 RepositoryRestConfiguration (英語) をカスタマイズする一連の有用なプロパティ（ spring.data.rest 名前空間から）を公開します。追加のカスタマイズを提供する必要がある場合は、 RepositoryRestConfigurer (英語) Beanを使用する必要があります。

カスタム RepositoryRestConfigurerで順序を指定しない場合、Spring Bootが内部的に使用した後に実行されます。順序を指定する必要がある場合は、0より大きいことを確認してください。

9.15. JPAによって使用されるコンポーネントを構成する

JPAが使用するコンポーネントを構成する場合は、JPAの前にコンポーネントが初期化されていることを確認する必要があります。コンポーネントが自動構成されると、Spring Bootがこれを処理します。例：Flywayが自動構成されている場合、HibernateはFlywayに依存するように構成されているため、FlywayはHibernateがデータベースを使用しようとする前にデータベースを初期化できます。

コンポーネントを自分で構成する場合は、EntityManagerFactoryDependsOnPostProcessor サブクラスを使用して、必要な依存関係をセットアップする便利な方法として使用できます。例：インデックスマネージャーとしてElasticsearchでHibernate Searchを使用する場合、次の例に示すように、EntityManagerFactory Beanは elasticsearchClient Beanに依存するように構成する必要があります。

/**
 * {@link EntityManagerFactoryDependsOnPostProcessor} that ensures that
 * {@link EntityManagerFactory} beans depend on the {@code elasticsearchClient} bean.
 */
@Component
static class ElasticsearchEntityManagerFactoryDependsOnPostProcessor
        extends EntityManagerFactoryDependsOnPostProcessor {

    ElasticsearchEntityManagerFactoryDependsOnPostProcessor() {
        super("elasticsearchClient");
    }

}

9.16. 2つのDataSourcesでjOOQを構成する

jOOQを複数のデータソースで使用する必要がある場合は、それぞれに対して独自の DSLContext を作成する必要があります。詳細については、JooqAutoConfiguration(GitHub) を参照してください。

特に、JooqExceptionTranslator および SpringTransactionProvider を再利用して、単一の DataSourceで自動構成が行うことと同様の機能を提供できます。

10. データベースの初期化

SQLデータベースは、スタックの種類に応じてさまざまな方法で初期化できます。もちろん、データベースが別のプロセスであれば、手動で行うこともできます。スキーマ生成には単一のメカニズムを使用することをお勧めします。

10.1. JPAを使用してデータベースを初期化する

JPAにはDDL生成のための機能があり、これらはデータベースに対して起動時に実行されるように設定できます。これは、2つの外部プロパティによって制御されます。

  • spring.jpa.generate-ddl （ブール型）は、機能のオンとオフを切り替え、ベンダーに依存しません。

  • spring.jpa.hibernate.ddl-auto （enum）は、よりきめ細かい方法で動作を制御するHibernate機能です。この機能については、このガイドの後半で詳しく説明します。

10.2. Hibernateを使用したデータベースの初期化

spring.jpa.hibernate.ddl-auto を明示的に設定でき、標準のHibernateプロパティ値は none, validate, update, createおよび create-dropです。Spring Bootは、データベースが埋め込まれていると考えるかどうかに基づいて、デフォルト値を選択します。スキーママネージャーが検出されなかった場合はデフォルトで create-drop になり、それ以外の場合は none になります。 Connection タイプを調べると、組み込みデータベースが検出されます。 hsqldb, h2および derby は埋め込まれていますが、その他は埋め込まれていません。メモリ内から「実際の」データベースに切り替えるときは、新しいプラットフォーム内のテーブルとデータの存在について仮定しないように注意してください。 ddl-auto を明示的に設定するか、他のメカニズムのいずれかを使用してデータベースを初期化する必要があります。

org.hibernate.SQL ロガーを有効にすることにより、スキーマ作成を出力できます。これは、デバッグモードを有効にすると自動的に行われます。

さらに、Hibernateが最初からスキーマを作成する場合（つまり、ddl-auto プロパティが create または create-dropに設定される場合）、クラスパスのルートにある import.sql という名前のファイルが起動時に実行されます。これは、デモや、慎重にテストする場合に役立ちますが、おそらく本番環境のクラスパスに配置したいものではありません。これはHibernate機能です（Springとは関係ありません）。

10.3. データベースを初期化する

Spring Bootは、DataSource のスキーマ（DDLスクリプト）を自動的に作成し、それを初期化できます（DMLスクリプト）。標準のルートクラスパスの場所、それぞれ schema.sql および data.sqlからSQLをロードします。さらに、Spring Bootは schema-${platform}.sql および data-${platform}.sql ファイル（存在する場合）を処理します。platform は spring.datasource.platformの値です。これにより、必要に応じてデータベース固有のスクリプトに切り替えることができます。例：データベースのベンダー名に設定することもできます（hsqldb, h2, oracle, mysql, postgresqlなど）。

Spring Bootは、埋め込み DataSourceのスキーマを自動的に作成します。この動作は、spring.datasource.initialization-mode プロパティを使用してカスタマイズできます。たとえば、タイプに関係なく DataSource を常に初期化する場合：

spring.datasource.initialization-mode=always

デフォルトでは、Spring BootはSpring JDBCイニシャライザーのフェイルファースト機能を有効にします。これは、スクリプトが例外を引き起こす場合、アプリケーションの起動に失敗することを意味します。 spring.datasource.continue-on-errorを設定することにより、その動作を調整できます。

JPAベースのアプリでは、Hibernateにスキーマを作成させるか、schema.sqlを使用させるかを選択できますが、両方を行うことはできません。 schema.sqlを使用する場合は、spring.jpa.hibernate.ddl-auto を必ず無効にしてください。

10.4. Spring Batchデータベースを初期化する

Spring Batchを使用する場合、ほとんどの一般的なデータベースプラットフォーム用のSQL初期化スクリプトがあらかじめパッケージ化されています。Spring Bootは、データベースタイプを検出し、起動時にこれらのスクリプトを実行できます。組み込みデータベースを使用する場合、これはデフォルトで行われます。次の例に示すように、任意のデータベースタイプに対して有効にすることもできます。

spring.batch.initialize-schema=always

spring.batch.initialize-schema=neverを設定して、初期化を明示的にオフにすることもできます。

10.5. 高レベルのデータベース移行ツールを使用する

Spring Bootは、Flyway(英語) とLiquibase(英語) の2つの高レベルの移行ツールをサポートしています。

10.5.1. 起動時にFlywayデータベース移行を実行する

起動時にFlywayデータベースの移行を自動的に実行するには、org.flywaydb:flyway-core をクラスパスに追加します。

通常、移行は V<VERSION>__<NAME>.sql という形式のスクリプトです（ <VERSION> では、「1」や「2_1」など、アンダースコアで区切られたバージョンです）。デフォルトでは、これらは classpath:db/migrationというフォルダーにありますが、spring.flyway.locationsを設定することでその場所を変更できます。これは、1つ以上の classpath: または filesystem: ロケーションのコンマ区切りリストです。例：次の構成は、デフォルトのクラスパスの場所と /opt/migration ディレクトリの両方でスクリプトを検索します。

spring.flyway.locations=classpath:db/migration,filesystem:/opt/migration

特別な {vendor} プレースホルダーを追加して、ベンダー固有のスクリプトを使用することもできます。以下を想定します。

spring.flyway.locations=classpath:db/migration/{vendor}

上記の構成では、db/migrationを使用するのではなく、データベースのタイプ（MySQLの db/migration/mysql など）に従って使用するフォルダーを設定します。サポートされているデータベースのリストは、 DatabaseDriver (GitHub) にあります。

移行はJavaで作成することもできます。Flywayは、JavaMigrationを実装するBeanで自動構成されます。

FlywayProperties (GitHub) は、Flywayのほとんどの設定と、移行を無効にするか、場所の確認をオフにするために使用できる追加プロパティの小さなセットを提供します。構成をさらに制御する必要がある場合は、FlywayConfigurationCustomizer Beanの登録を検討してください。

Spring Bootは Flyway.migrate() を呼び出して、データベースの移行を実行します。さらに制御したい場合は、 FlywayMigrationStrategy (GitHub) を実装する @Bean を提供してください。

Flywayは、SQLおよびJava コールバック(英語) をサポートしています。SQLベースのコールバックを使用するには、classpath:db/migration フォルダーにコールバックスクリプトを配置します。Javaベースのコールバックを使用するには、Callbackを実装する1つ以上のBeanを作成します。そのようなBeanはすべて Flywayに自動的に登録されます。それらは、@Order を使用するか、Orderedを実装することでオーダーできます。非推奨の FlywayCallback インターフェースを実装するBeanも検出できますが、Callback Beanと一緒に使用することはできません。

デフォルトでは、Flywayはコンテキスト内で（@Primary） DataSource をオートワイヤーし、それを移行に使用します。別の DataSourceを使用する場合は、作成して、@Bean を @FlywayDataSourceとしてマークできます。その場合、2つのデータソースが必要な場合は、別のデータソースを作成して、@Primaryとしてマークすることを忘れないでください。あるいは、外部プロパティで spring.flyway.[url,user,password] を設定することにより、Flywayのネイティブ DataSource を使用できます。 spring.flyway.url または spring.flyway.user のいずれかを設定するだけで、Flywayが独自の DataSourceを使用できます。3つのプロパティのいずれかが設定されていない場合、同等の spring.datasource プロパティの値が使用されます。

Flywayを使用して、特定のシナリオのデータを提供することもできます。例：テスト固有の移行を src/test/resources に配置できます。これらの移行は、テストのためにアプリケーションが開始されたときにのみ実行されます。また、特定のプロファイルがアクティブな場合にのみ特定の移行が実行されるように、プロファイル固有の構成を使用して spring.flyway.locations をカスタマイズできます。例： application-dev.propertiesでは、次の設定を指定できます。

spring.flyway.locations=classpath:/db/migration,classpath:/dev/db/migration

その設定では、dev/db/migration の移行は、dev プロファイルがアクティブな場合にのみ実行されます。

10.5.2. 起動時にLiquibaseデータベースの移行を実行する

起動時にLiquibaseデータベースの移行を自動的に実行するには、クラスパスに org.liquibase:liquibase-core を追加します。

デフォルトでは、マスター変更ログは db/changelog/db.changelog-master.yamlから読み取られますが、spring.liquibase.change-logを設定して場所を変更できます。YAMLに加えて、LiquibaseはJSON、XML、およびSQL変更ログ形式もサポートしています。

デフォルトでは、Liquibaseはコンテキストで（@Primary） DataSource をオートワイヤーし、それを移行に使用します。別の DataSourceを使用する必要がある場合は、作成して、その @Bean を @LiquibaseDataSourceとしてマークできます。そのようにして、2つのデータソースが必要な場合は、別のデータソースを作成して、@Primaryとしてマークすることを忘れないでください。または、外部プロパティで spring.liquibase.[url,user,password] を設定して、Liquibaseのネイティブ DataSource を使用できます。Liquibaseが独自の DataSourceを使用するには、spring.liquibase.url または spring.liquibase.user のいずれかを設定するだけで十分です。3つのプロパティのいずれかが設定されていない場合、同等の spring.datasource プロパティの値が使用されます。

コンテキスト、デフォルトスキーマなどの利用可能な設定の詳細については、 LiquibaseProperties (GitHub) を参照してください。

11. メッセージング

Spring Bootは、メッセージングを含む多くのスターターを提供します。このセクションでは、Spring Bootでメッセージングを使用することから生じる質問に回答します。

11.1. トランザクションJMSセッションを無効にする

JMSブローカーがトランザクションセッションをサポートしていない場合、トランザクションのサポートを完全に無効にする必要があります。独自の JmsListenerContainerFactoryを作成する場合、デフォルトではトランザクションを処理できないため、実行することはありません。 DefaultJmsListenerContainerFactoryConfigurer を使用してSpring Bootのデフォルトを再利用する場合、次のようにトランザクションセッションを無効にできます。

@Bean
public DefaultJmsListenerContainerFactory jmsListenerContainerFactory(
        ConnectionFactory connectionFactory,
        DefaultJmsListenerContainerFactoryConfigurer configurer) {
    DefaultJmsListenerContainerFactory listenerFactory =
            new DefaultJmsListenerContainerFactory();
    configurer.configure(listenerFactory, connectionFactory);
    listenerFactory.setTransactionManager(null);
    listenerFactory.setSessionTransacted(false);
    return listenerFactory;
}

前述の例はデフォルトのファクトリをオーバーライドします。アプリケーションが定義する他のファクトリがある場合は、それを適用する必要があります。

12. バッチアプリケーション

Spring Bootアプリケーション内からSpring Batchを使用する場合、多くの質問がしばしば発生します。このセクションでは、これらの質問に対処します。

12.1. バッチデータソースの指定

デフォルトでは、バッチアプリケーションには、ジョブの詳細を保存するために DataSource が必要です。Spring Batchは、デフォルトで単一の DataSource を想定しています。アプリケーションのメイン DataSource以外の DataSource を使用するには、DataSource Beanを宣言し、@BatchDataSourceで @Bean メソッドにアノテーションを付けます。その場合、2つのデータソースが必要な場合は、もう1つのデータソースを @Primaryとしてマークすることを忘れないでください。制御を強化するには、BatchConfigurerを実装します。詳細については、 @EnableBatchProcessingのJavadoc を参照してください。

Spring Batchの詳細については、Spring Batchプロジェクトページを参照してください。

12.2. 起動時にSpring Batchジョブを実行する

@EnableBatchProcessing を @Configuration クラスの1つに追加すると、Spring Batchの自動構成が有効になります。

デフォルトでは、起動時にアプリケーションコンテキストですべての Jobs を実行します（詳細については JobLauncherCommandLineRunner (GitHub) を参照）。 spring.batch.job.names （ジョブ名パターンのコンマ区切りリストを使用）を指定することにより、特定のジョブに絞り込むことができます。

詳細については、BatchAutoConfiguration(GitHub) および@EnableBatchProcessing(Javadoc) を参照してください。

12.3. コマンドラインから実行する

コマンドラインからSpring Bootを使用してSpring Batchを実行することは、コマンドラインからSpring Batchを単独で実行することとは異なります。最も重要な違いは、次のセクションで説明するように、コマンドライン引数を異なる方法で解析するため、問題が発生する可能性があることです。

12.3.1. コマンドライン引数を渡す

Spring Bootは、-- で始まるコマンドライン引数をプロパティに変換して、Environmentに追加します。コマンドラインプロパティへのアクセスを参照してください。これは、バッチジョブに引数を渡すために使用しないでください。コマンドラインでバッチ引数を指定するには、次の例に示すように、通常の形式（つまり --なし）を使用します。

$ java -jar myapp.jar someParameter=someValue anotherParameter=anotherValue

コマンドラインで Environment のプロパティを指定すると、ジョブが使用する引数にも影響します。次のコマンドを検討してください。

$ java -jar myapp.jar --server.port=7070 someParameter=someValue

これにより、バッチジョブに2つの引数 someParameter=someValue および -server.port=7070が提供されます。Spring Batchは、存在する場合、プロパティの最初の - 文字を削除するため、2番目の引数には1つのハイフンがありません。

12.4. ジョブリポジトリの保存

Spring Batchでは、Job リポジトリ用のデータストアが必要です。Spring Bootを使用する場合、実際のデータベースを使用する必要があります。インメモリデータベースでもかまいません。ジョブリポジトリの構成を参照してください。

13. アクチュエーター

Spring BootにはSpring Boot Actuatorが含まれます。このセクションでは、その使用からしばしば生じる質問に回答します。

13.1. アクチュエーターエンドポイントのHTTPポートまたはアドレスを変更する

スタンドアロンアプリケーションでは、アクチュエーターのHTTPポートはデフォルトでメインHTTPポートと同じになります。アプリケーションが別のポートでリッスンするようにするには、外部プロパティ management.server.portを設定します。管理用の内部ネットワークとユーザーアプリケーション用の外部ネットワークがある場合など、完全に異なるネットワークアドレスでリッスンするために、management.server.address をサーバーがバインドできる有効なIPアドレスに設定することもできます。

詳細については、 ManagementServerProperties (GitHub) ソースコードおよび「Production-ready features」セクションの「production-ready-features.html」を参照してください。

13.2. 「ホワイトラベル」エラーページをカスタマイズする

Spring Bootは、サーバーエラーが発生した場合にブラウザークライアントに表示される「ホワイトラベル」エラーページをインストールします（JSONおよびその他のメディアタイプを使用するマシンクライアントは、適切なエラーコードで適切な応答を確認する必要があります）。

server.error.whitelabel.enabled=false を設定して、デフォルトのエラーページをオフにします。これにより、使用しているサーブレットコンテナーのデフォルトが復元されます。Spring Bootは引き続きエラービューの解決を試みるため、完全に無効にするのではなく、おそらく独自のエラーページを追加する必要があります。

エラーページを独自のもので上書きするかどうかは、使用するテンプレートテクノロジによって異なります。例：Thymeleafを使用する場合、error.html テンプレートを追加できます。FreeMarkerを使用する場合、error.ftlh テンプレートを追加できます。一般的に、error または /error パスを処理する @Controller の名前で解決される View が必要です。いくつかのデフォルト構成を置き換えない限り、ApplicationContextで BeanNameViewResolver を見つける必要があります。そのため、error という名前の @Bean がそれを行う簡単な方法です。その他のオプションについては、 ErrorMvcAutoConfiguration (GitHub) を参照してください。

サーブレットコンテナーにハンドラを登録する方法の詳細については、「エラー処理」のセクションも参照してください。

13.3. 実用的な価値観をサニタイズする

env エンドポイントと configprops エンドポイントによって返される情報はやや機密性が高いため、特定のパターンに一致するキーはデフォルトでサニタイズされます（つまり、それらの値は ******に置き換えられます）。

Spring Bootは、このようなキーに適切なデフォルトを使用します。たとえば、「password」、「secret」、「key」、または「token」という単語で終わるキーはサニタイズされます。 *credentials.* などの正規表現を代わりに使用して、credentials という単語をキーの一部として保持するキーをサニタイズすることもできます。

使用するパターンは、それぞれ management.endpoint.env.keys-to-sanitize と management.endpoint.configprops.keys-to-sanitize を使用してカスタマイズできます。

14. セキュリティ

このセクションでは、Spring BootでSpring Securityを使用することから生じる質問を含む、Spring Bootを使用する際のセキュリティに関する質問について説明します。

Spring Securityの詳細については、Spring Securityプロジェクトページを参照してください。

14.1. Spring Bootセキュリティ構成をオフにする

アプリケーションで @Configuration を WebSecurityConfigurerAdapter で定義すると、Spring Bootのデフォルトのwebappセキュリティ設定がオフになります。

14.2. UserDetailsServiceの変更とユーザーアカウントの追加

タイプ AuthenticationManager, AuthenticationProviderまたは UserDetailsServiceの @Bean を提供する場合、InMemoryUserDetailsManager のデフォルト @Bean は作成されません。これは、Spring Securityの完全な機能セット（ さまざまな認証オプションなど）を使用できることを意味します。

ユーザーアカウントを追加する最も簡単な方法は、独自の UserDetailsService Beanを提供することです。

14.3. プロキシサーバーの背後で実行するときにHTTPSを有効にする

すべてのメインエンドポイントがHTTPS経由でのみ使用できるようにすることは、アプリケーションにとって重要な作業です。Tomcatをサーブレットコンテナーとして使用している場合、Spring Bootは、一部の環境設定を検出するとTomcat自身の RemoteIpValve を自動的に追加し、HttpServletRequest に依存して、安全かどうか（処理するプロキシサーバーの下流であっても）を報告できるはずです実際のSSL終了）。標準の動作は、名前が従来のものである特定の要求ヘッダー（x-forwarded-for および x-forwarded-proto）の有無によって決定されるため、ほとんどのフロントエンドプロキシで動作するはずです。次の例に示すように、application.propertiesにいくつかのエントリを追加することにより、バルブをオンに切り替えることができます。

server.tomcat.remote-ip-header=x-forwarded-for
server.tomcat.protocol-header=x-forwarded-proto

（これらのプロパティのいずれかが存在すると、バルブが切り替わります。または、TomcatServletWebServerFactory Beanを追加して RemoteIpValve を追加できます。）

Spring Securityを構成して、すべての（または一部の）要求にセキュアチャネルを要求するには、次の HttpSecurity 構成を追加する独自の WebSecurityConfigurerAdapter を追加することを検討してください。

@Configuration(proxyBeanMethods = false)
public class SslWebSecurityConfigurerAdapter extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        // Customize the application security
        http.requiresChannel().anyRequest().requiresSecure();
    }

}

15. ホットスワップ

Spring Bootはホットスワップをサポートしています。このセクションでは、その仕組みに関する質問に回答します。

15.1. 静的コンテンツをリロードする

ホットリロードにはいくつかのオプションがあります。推奨されるアプローチは spring-boot-devtools を使用することです。これは、アプリケーションの高速再起動やLiveReloadのサポートなどの追加の開発時機能、および実用的な開発時設定（テンプレートキャッシングなど）を提供するためです。Devtoolsは、クラスパスの変更を監視することで機能します。つまり、変更を有効にするには、静的リソースの変更を「構築」する必要があります。デフォルトでは、変更を保存すると、Eclipseでこれが自動的に行われます。IntelliJ IDEAでは、プロジェクトの作成コマンドが必要なビルドをトリガーします。デフォルトの再起動の除外により、静的リソースを変更してもアプリケーションの再起動はトリガーされません。ただし、ライブリロードはトリガーされます。

あるいは、IDEで実行する（特にデバッグをオンにした）ことは、開発を行うための良い方法です（すべての最新のIDEは静的リソースの再読み込みを許可し、通常Javaクラス変更のホットスワップも許可します）。

最後に、MavenおよびGradleプラグインを構成して（ addResources プロパティを参照）、ソースから直接静的ファイルをリロードするコマンドラインからの実行をサポートできます。より高いレベルのツールを使用してコードを記述している場合は、外部のcss / jsコンパイラプロセスで使用できます。

15.2. コンテナーを再起動せずにテンプレートをリロードする

Spring Bootでサポートされるほとんどのテンプレートテクノロジには、キャッシュを無効にする構成オプションが含まれています（このドキュメントで後述）。 spring-boot-devtools モジュールを使用する場合、これらのプロパティは開発時に自動的に構成されます。

15.2.1. Thymeleafテンプレート

Thymeleafを使用する場合は、spring.thymeleaf.cache を falseに設定します。他のThymeleafカスタマイズオプションについては、 ThymeleafAutoConfiguration (GitHub) を参照してください。

15.2.2. FreeMarkerテンプレート

FreeMarkerを使用する場合は、spring.freemarker.cache を falseに設定します。他のFreeMarkerカスタマイズオプションについては、 FreeMarkerAutoConfiguration (GitHub) を参照してください。

15.2.3. Groovy テンプレート

Groovyテンプレートを使用する場合、spring.groovy.template.cache を falseに設定します。他のGroovyカスタマイズオプションについては、 GroovyTemplateAutoConfiguration (GitHub) を参照してください。

15.3. 高速アプリケーション再起動

spring-boot-devtools モジュールには、自動アプリケーション再起動のサポートが含まれています。JRebel(英語) などのテクノロジーほど高速ではありませんが、通常は「コールドスタート」よりも大幅に高速です。このドキュメントで後述する、より複雑なリロードオプションのいくつかを調査する前に、おそらく試してみるべきです。

詳細については、using-spring-boot.htmlセクションを参照してください。

15.4. コンテナーを再起動せずにJavaクラスをリロードする

最新のIDE（Eclipse、IDEAなど）の多くは、バイトコードのホットスワップをサポートしています。クラスまたはメソッドのシグネチャーに影響を与えない変更を加えた場合、副作用なしできれいにリロードする必要があります。

16. ビルド

Spring Bootには、MavenおよびGradleのビルドプラグインが含まれています。このセクションでは、これらのプラグインに関する一般的な質問に回答します。

16.1. ビルド情報を生成する

MavenプラグインとGradleプラグインの両方で、プロジェクトの座標、名前、およびバージョンを含むビルド情報を生成できます。プラグインは、構成によって追加のプロパティを追加するように構成することもできます。そのようなファイルが存在する場合、Spring Bootは BuildProperties Beanを自動構成します。

Mavenでビルド情報を生成するには、次の例に示すように、build-info ゴールの実行を追加します。

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <version>2.2.4.RELEASE</version>
            <executions>
                <execution>
                    <goals>
                        <goal>build-info</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>
詳細については、Spring Boot Mavenプラグインのドキュメントを参照してください。

次の例は、Gradleでも同じことを行います。

springBoot {
    buildInfo()
}
詳細については、Spring Boot Gradleプラグインのドキュメントを参照してください。

16.2. Git情報を生成する

MavenとGradleの両方により、プロジェクトのビルド時の git ソースコードリポジトリの状態に関する情報を含む git.properties ファイルを生成できます。

Mavenユーザーの場合、spring-boot-starter-parent POMには、git.properties ファイルを生成するための事前構成プラグインが含まれています。それを使用するには、次の宣言をPOMに追加します。

<build>
    <plugins>
        <plugin>
            <groupId>pl.project13.maven</groupId>
            <artifactId>git-commit-id-plugin</artifactId>
        </plugin>
    </plugins>
</build>

Gradleユーザーは、次の例に示すように、 gradle-git-properties (英語) プラグインを使用して同じ結果を得ることができます。

plugins {
    id "com.gorylenko.gradle-git-properties" version "1.5.1"
}
git.properties のコミット時間は、次の形式と一致することが予想されます： yyyy-MM-dd’T’HH:mm:ssZ。これは、上記の両方のプラグインのデフォルト形式です。この形式を使用すると、時間を解析して Date に変換し、その形式をJSONに直列化するときに、Jacksonの日付の直列化構成設定で制御できます。

16.3. 依存関係バージョンのカスタマイズ

spring-boot-dependencies （たとえば、spring-boot-starter-parent）から直接または間接的に継承するMavenビルドを使用しているが、特定のサードパーティの依存関係をオーバーライドする場合、適切な <properties> 要素を追加できます。プロパティの完全なリストについては、 spring-boot-dependencies (GitHub) POMを参照してください。例：別の slf4j バージョンを選択するには、次のプロパティを追加します。

<properties>
    <slf4j.version>1.7.5<slf4j.version>
</properties>
これは、Mavenプロジェクトが spring-boot-dependenciesから（直接的または間接的に）継承する場合にのみ機能します。 <scope>import</scope>で dependencyManagement セクションに spring-boot-dependencies を追加した場合、プロパティをオーバーライドする代わりに、自分でアーティファクトを再定義する必要があります。
各Spring Bootリリースは、この特定のサードパーティ依存関係セットに対して設計およびテストされています。バージョンを上書きすると、互換性の課題が発生する場合があります。

Gradleの依存バージョンをオーバーライドするには、Gradleプラグインのドキュメントのこのセクションを参照してください。

16.4. Mavenを使用して実行可能JARを作成する

spring-boot-maven-plugin を使用して、実行可能な「fat 」JARを作成できます。 spring-boot-starter-parent POMを使用する場合、プラグインを宣言でき、jarは次のように再パッケージ化されます。

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

親POMを使用しない場合でも、プラグインを使用できます。ただし、次のように <executions> セクションを追加する必要があります。

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <version>2.2.4.RELEASE</version>
            <executions>
                <execution>
                    <goals>
                        <goal>repackage</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

使用方法の詳細については、プラグインのドキュメントを参照してください。

16.5. Spring Bootアプリケーションを依存関係として使用する

warファイルのように、Spring Bootアプリケーションは依存関係として使用されることを意図していません。アプリケーションに他のプロジェクトと共有するクラスが含まれている場合、推奨されるアプローチは、そのコードを別のモジュールに移動することです。個別のモジュールは、アプリケーションや他のプロジェクトに依存できます。

上記の推奨に従ってコードを再配置できない場合、Spring BootのMavenおよびGradleプラグインは、依存関係としての使用に適した個別のアーティファクトを生成するように構成する必要があります。実行可能jar形式は BOOT-INF/classesのアプリケーションクラスをパッケージ化するため、実行可能アーカイブは依存関係として使用できません。つまり、実行可能ファイルjarが依存関係として使用されている場合、それらは見つかりません。

依存関係として使用できるアーティファクトと実行可能なアーティファクトを生成するには、分類子を指定する必要があります。この分類子は、実行可能アーカイブの名前に適用され、デフォルトのアーカイブは依存関係として使用されます。

Mavenで exec の分類子を構成するには、次の構成を使用できます。

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

16.6. 実行可能Jarの実行時に特定のライブラリを抽出する

実行可能jarのネストされたライブラリのほとんどは、実行するために解凍する必要はありません。ただし、特定のライブラリには問題がある場合があります。例：JRubyには、独自のネストされたjarサポートが含まれています。これは、jruby-complete.jar が常に独自のファイルとして直接利用可能であることを前提としています。

問題のあるライブラリを処理するために、実行可能ファイルjarが最初に実行されるときに、特定のネストされたjarが自動的に解凍されるようにフラグを立てることができます。このようなネストされたjarは、java.io.tmpdir システムプロパティによって識別される一時ディレクトリに書き込まれます。

アプリケーションの実行中に一時ディレクトリに解凍されたjarファイルが削除されないように、オペレーティングシステムが設定されていることを確認する必要があります。

例：Mavenプラグインを使用して、JRubyに解凍用のフラグを設定する必要があることを示すには、次の構成を追加します。

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <configuration>
                <requiresUnpack>
                    <dependency>
                        <groupId>org.jruby</groupId>
                        <artifactId>jruby-complete</artifactId>
                    </dependency>
                </requiresUnpack>
            </configuration>
        </plugin>
    </plugins>
</build>

16.7. 除外付きの非実行可能JARを作成する

多くの場合、2つの別個のビルド製品として実行可能ファイルと実行不可能なjarがある場合、実行可能バージョンにはライブラリjarで必要のない追加の構成ファイルがあります。例： application.yml 構成ファイルは、実行不可能なJARから除外される場合があります。

Mavenでは、実行可能なjarがメインアーティファクトである必要があり、次のように、ライブラリに分類されたjarを追加できます。

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>
        <plugin>
            <artifactId>maven-jar-plugin</artifactId>
            <executions>
                <execution>
                    <id>lib</id>
                    <phase>package</phase>
                    <goals>
                        <goal>jar</goal>
                    </goals>
                    <configuration>
                        <classifier>lib</classifier>
                        <excludes>
                            <exclude>application.yml</exclude>
                        </excludes>
                    </configuration>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

16.8. リモート Mavenで開始したSpring Bootアプリケーションのデバッグ

Mavenで開始されたSpring Bootアプリケーションにリモートデバッガーを接続するには、mavenプラグインの jvmArguments プロパティを使用できます。

詳細については、この例を参照してください。

16.9. spring-boot-antlibを使用せずにAntから実行可能アーカイブを構築する

Antでビルドするには、依存関係を取得し、コンパイルしてから、jarまたはwarアーカイブを作成する必要があります。実行可能にするには、spring-boot-antlib モジュールを使用するか、次の指示に従ってください。

  1. jarを構築している場合、ネストされた BOOT-INF/classes ディレクトリにアプリケーションのクラスとリソースをパッケージ化します。warを構築する場合は、通常どおり、ネストされた WEB-INF/classes ディレクトリにアプリケーションのクラスをパッケージ化します。

  2. jarのネストされた BOOT-INF/lib ディレクトリまたはwarの WEB-INF/lib にランタイム依存関係を追加します。アーカイブ内のエントリを圧縮しないでください。

  3. jarの場合はネストされた BOOT-INF/lib ディレクトリに、warの場合は WEB-INF/lib-provided に、provided （組み込みコンテナー）依存関係を追加します。アーカイブ内のエントリを圧縮しないでください。

  4. spring-boot-loader クラスをアーカイブのルートに追加します（ Main-Class が利用できるように）。

  5. 適切なランチャー（jarファイルの JarLauncher など）をマニフェストの Main-Class 属性として使用し、必要な他のプロパティをマニフェストエントリとして指定します。主に、Start-Class プロパティを設定します。

次の例は、Antを使用して実行可能アーカイブを構築する方法を示しています。

<target name="build" depends="compile">
    <jar destfile="target/${ant.project.name}-${spring-boot.version}.jar" compress="false">
        <mappedresources>
            <fileset dir="target/classes" />
            <globmapper from="*" to="BOOT-INF/classes/*"/>
        </mappedresources>
        <mappedresources>
            <fileset dir="src/main/resources" erroronmissingdir="false"/>
            <globmapper from="*" to="BOOT-INF/classes/*"/>
        </mappedresources>
        <mappedresources>
            <fileset dir="${lib.dir}/runtime" />
            <globmapper from="*" to="BOOT-INF/lib/*"/>
        </mappedresources>
        <zipfileset src="${lib.dir}/loader/spring-boot-loader-jar-${spring-boot.version}.jar" />
        <manifest>
            <attribute name="Main-Class" value="org.springframework.boot.loader.JarLauncher" />
            <attribute name="Start-Class" value="${start-class}" />
        </manifest>
    </jar>
</target>

17. 従来のデプロイ

Spring Bootは、従来のデプロイだけでなく、より新しい形式のデプロイもサポートします。このセクションでは、従来のデプロイに関する一般的な質問に回答します。

17.1. デプロイ可能なWarファイルを作成する

Spring WebFluxはサーブレットAPIに厳密に依存せず、アプリケーションはデフォルトで組み込みReactor Nettyサーバーにデプロイされるため、War デプロイはWebFluxアプリケーションではサポートされていません。

デプロイ可能なwarファイルを作成する最初のステップは、SpringBootServletInitializer サブクラスを提供し、その configure メソッドをオーバーライドすることです。これにより、Spring Frameworkのサーブレット3.0サポートが利用され、サーブレットコンテナーによって起動されたときにアプリケーションを構成できます。通常、次の例に示すように、SpringBootServletInitializerを継承するには、アプリケーションのメインクラスを更新する必要があります。

@SpringBootApplication
public class Application extends SpringBootServletInitializer {

    @Override
    protected SpringApplicationBuilder configure(SpringApplicationBuilder application) {
        return application.sources(Application.class);
    }

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

}

次のステップは、プロジェクトがjarファイルではなくwarファイルを生成するようにビルド構成を更新することです。Mavenと spring-boot-starter-parent （Mavenのwarプラグインを構成します）を使用する場合は、次のように pom.xml を変更してパッケージをwarに変更するだけです。

<packaging>war</packaging>

Gradleを使用する場合は、build.gradle を変更して、次のようにwarプラグインをプロジェクトに適用する必要があります。

apply plugin: 'war'

プロセスの最後のステップは、組み込みサーブレットコンテナーがwarファイルのデプロイ先のサーブレットコンテナーと干渉しないようにすることです。そのためには、埋め込まれたサーブレットコンテナーの依存関係を提供済みとしてマークする必要があります。

Mavenを使用する場合、次の例では、サーブレットコンテナー（この場合はTomcat）が提供されているとマークします。

<dependencies>
    <!-- … -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-tomcat</artifactId>
        <scope>provided</scope>
    </dependency>
    <!-- … -->
</dependencies>

Gradleを使用する場合、次の例では、サーブレットコンテナー（この場合はTomcat）が提供されているとマークします。

dependencies {
    // …
    providedRuntime 'org.springframework.boot:spring-boot-starter-tomcat'
    // …
}
providedRuntime は、Gradleの compileOnly 構成よりも優先されます。他の制限の中でも、compileOnly 依存関係はテストクラスパスにないため、Webベースの統合テストはすべて失敗します。

Spring Bootビルドツールを使用する場合、組み込みサーブレットコンテナーの依存関係を提供済みとしてマークすると、提供された依存関係が lib-provided ディレクトリにパッケージ化された実行可能なwarファイルが生成されます。つまり、サーブレットコンテナーにデプロイできることに加えて、コマンドラインで java -jar を使用してアプリケーションを実行することもできます。

17.2. 既存のアプリケーションをSpring Bootに変換する

非Webアプリケーションの場合、既存のSpringアプリケーションをSpring Bootアプリケーションに簡単に変換できるはずです。そのためには、ApplicationContext を作成するコードを破棄し、SpringApplication または SpringApplicationBuilderの呼び出しに置き換えます。Spring MVC Webアプリケーションは、通常、最初にデプロイ可能なwarアプリケーションを作成し、それを後で実行可能なwarまたはjarに移行するのに適しています。jarからwarへの変換に関する入門ガイドを参照してください。

SpringBootServletInitializer を継承して（たとえば Applicationというクラスに）、Spring Boot @SpringBootApplication アノテーションを追加してデプロイ可能なwarを作成するには、次の例に示すようなコードを使用します。

@SpringBootApplication
public class Application extends SpringBootServletInitializer {

    @Override
    protected SpringApplicationBuilder configure(SpringApplicationBuilder application) {
        // Customize the application or call application.sources(...) to add sources
        // Since our example is itself a @Configuration class (via @SpringBootApplication)
        // we actually don't need to override this method.
        return application;
    }

}

sources に入れるものはすべてSpring ApplicationContextに過ぎないことを忘れないでください。通常、すでに動作しているものはすべてここで動作するはずです。後で削除できるBeanがあり、Spring Bootに独自のデフォルトを提供させることもありますが、それを行う前に何かを機能させることができるはずです。

静的リソースは、クラスパスルートの /public （または /static または /resources または /META-INF/resources）に移動できます。同じことが messages.properties （Spring Bootがクラスパスのルートで自動的に検出します）にも当てはまります。

Spring DispatcherServlet およびSpring SecurityのVanillaの使用には、それ以上の変更は不要です。アプリケーションに他の機能がある場合（たとえば、他のサーブレットやフィルターを使用する場合）、web.xmlの要素を次のように置き換えることにより、Application コンテキストに設定を追加する必要がある場合があります。

  • タイプ Servlet または ServletRegistrationBean の @Bean は、あたかも web.xmlの <servlet/> および <servlet-mapping/> であるかのように、そのBeanをコンテナーにインストールします。

  • タイプ Filter または FilterRegistrationBean の @Bean は、同様に動作します（ <filter/> および <filter-mapping/>として）。

  • XMLファイルの ApplicationContext は、Applicationの @ImportResource を介して追加できます。あるいは、アノテーション構成がすでに頻繁に使用されている単純なケースは、数行で @Bean 定義として再作成できます。

warファイルが機能したら、次の例に示すように、main メソッドを Applicationに追加して実行可能にすることができます。

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

アプリケーションをwarまたは実行可能アプリケーションとして開始する場合は、SpringBootServletInitializer コールバックと次のようなクラスの main メソッドの両方で使用可能なメソッドでビルダーのカスタマイズを共有する必要があります。

@SpringBootApplication
public class Application extends SpringBootServletInitializer {

    @Override
    protected SpringApplicationBuilder configure(SpringApplicationBuilder builder) {
        return configureApplication(builder);
    }

    public static void main(String[] args) {
        configureApplication(new SpringApplicationBuilder()).run(args);
    }

    private static SpringApplicationBuilder configureApplication(SpringApplicationBuilder builder) {
        return builder.sources(Application.class).bannerMode(Banner.Mode.OFF);
    }

}

アプリケーションは複数のカテゴリに分類できます。

  • web.xmlのないサーブレット3.0+アプリケーション。

  • web.xmlを使用したアプリケーション。

  • コンテキスト階層を持つアプリケーション。

  • コンテキスト階層のないアプリケーション。

これらはすべて翻訳に適しているはずですが、それぞれがわずかに異なる技術を必要とする場合があります。

すでにSpringサーブレット3.0+初期化子サポートクラスを使用している場合、サーブレット3.0+アプリケーションは非常に簡単に変換できます。通常、既存の WebApplicationInitializer のすべてのコードを SpringBootServletInitializerに移動できます。既存のアプリケーションに複数の ApplicationContext がある場合（たとえば、AbstractDispatcherServletInitializerを使用する場合）、すべてのコンテキストソースを単一の SpringApplicationに結合できる場合があります。発生する可能性のある主な問題は、結合が機能せず、コンテキスト階層を維持する必要がある場合です。例については、階層の構築に関するエントリを参照してください。通常、Web固有の機能を含む既存の親コンテキストは、すべての ServletContextAware コンポーネントが子コンテキストに含まれるように分割する必要があります。

まだSpringアプリケーションではないアプリケーションは、Spring Bootアプリケーションに変換できる場合があり、前述のガイダンスが役立つ場合があります。ただし、まだ問題が発生する場合があります。その場合は、 spring-bootのタグを使用してStack Overflowで質問する(英語) ことをお勧めします。

17.3. WebLogicへのWARのデプロイ

Spring BootアプリケーションをWebLogicにデプロイするには、サーブレット初期化子が WebApplicationInitializer を直接実装していることを確認する必要があります（すでに実装している基本クラスから拡張する場合でも）。

WebLogicの一般的な初期化子は、次の例のようになります。

import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.web.servlet.support.SpringBootServletInitializer;
import org.springframework.web.WebApplicationInitializer;

@SpringBootApplication
public class MyApplication extends SpringBootServletInitializer implements WebApplicationInitializer {

}

Logbackを使用する場合は、WebLogicに、サーバーにプリインストールされているバージョンではなく、パッケージ化されたバージョンを優先するように指示する必要もあります。これを行うには、次の内容の WEB-INF/weblogic.xml ファイルを追加します。

<?xml version="1.0" encoding="UTF-8"?>
<wls:weblogic-web-app
    xmlns:wls="http://xmlns.oracle.com/weblogic/weblogic-web-app"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
        https://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd
        http://xmlns.oracle.com/weblogic/weblogic-web-app
        https://xmlns.oracle.com/weblogic/weblogic-web-app/1.4/weblogic-web-app.xsd">
    <wls:container-descriptor>
        <wls:prefer-application-packages>
            <wls:package-name>org.slf4j</wls:package-name>
        </wls:prefer-application-packages>
    </wls:container-descriptor>
</wls:weblogic-web-app>

17.4. Lettuceの代わりにJedisを使用する

デフォルトでは、Spring Bootスターター（spring-boot-starter-data-redis）はLettuce(GitHub) を使用します。その依存関係を除外し、代わりにJedis(GitHub) を含める必要があります。Spring Bootはこれらの依存関係を管理して、このプロセスを可能な限り簡単にします。

次の例は、Mavenでこれを行う方法を示しています。

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
    <exclusions>
        <exclusion>
            <groupId>io.lettuce</groupId>
            <artifactId>lettuce-core</artifactId>
        </exclusion>
    </exclusions>
</dependency>
<dependency>
    <groupId>redis.clients</groupId>
    <artifactId>jedis</artifactId>
</dependency>

次の例は、Gradleでこれを行う方法を示しています。

configurations {
    compile.exclude module: "lettuce"
}

dependencies {
    compile("redis.clients:jedis")
    // ...
}

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