従来のデプロイ

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

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

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

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

  • Java

  • Kotlin

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.builder.SpringApplicationBuilder;
import org.springframework.boot.web.servlet.support.SpringBootServletInitializer;

@SpringBootApplication
public class MyApplication extends SpringBootServletInitializer {

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

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

}
import org.springframework.boot.autoconfigure.SpringBootApplication
import org.springframework.boot.builder.SpringApplicationBuilder
import org.springframework.boot.runApplication
import org.springframework.boot.web.servlet.support.SpringBootServletInitializer

@SpringBootApplication
class MyApplication : SpringBootServletInitializer() {

	override fun configure(application: SpringApplicationBuilder): SpringApplicationBuilder {
		return application.sources(MyApplication::class.java)
	}

}

fun main(args: Array<String>) {
	runApplication<MyApplication>(*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 を使用してアプリケーションを実行することもできます。

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

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

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

  • Java

  • Kotlin

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.builder.SpringApplicationBuilder;
import org.springframework.boot.web.servlet.support.SpringBootServletInitializer;

@SpringBootApplication
public class MyApplication 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 (through
		// @SpringBootApplication)
		// we actually do not need to override this method.
		return application;
	}


}
import org.springframework.boot.autoconfigure.SpringBootApplication
import org.springframework.boot.builder.SpringApplicationBuilder
import org.springframework.boot.runApplication
import org.springframework.boot.web.servlet.support.SpringBootServletInitializer

@SpringBootApplication
class MyApplication : SpringBootServletInitializer() {

	override fun configure(application: SpringApplicationBuilder): SpringApplicationBuilder {
		// Customize the application or call application.sources(...) to add sources
		// Since our example is itself a @Configuration class (through @SpringBootApplication)
		// we actually do not 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 のバニラ使用には、それ以上の変更は必要ありません。アプリケーションに他の機能がある場合（たとえば、他のサーブレットやフィルターを使用する場合）、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 に追加して実行可能にすることができます。

  • Java

  • Kotlin

	public static void main(String[] args) {
		SpringApplication.run(MyApplication.class, args);
	}
fun main(args: Array<String>) {
	runApplication<MyApplication>(*args)
}

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

  • Java

  • Kotlin

import org.springframework.boot.Banner;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.builder.SpringApplicationBuilder;
import org.springframework.boot.web.servlet.support.SpringBootServletInitializer;

@SpringBootApplication
public class MyApplication extends SpringBootServletInitializer {

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

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

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

}
import org.springframework.boot.Banner
import org.springframework.boot.autoconfigure.SpringBootApplication
import org.springframework.boot.builder.SpringApplicationBuilder
import org.springframework.boot.web.servlet.support.SpringBootServletInitializer

@SpringBootApplication
class MyApplication : SpringBootServletInitializer() {

	override fun configure(builder: SpringApplicationBuilder): SpringApplicationBuilder {
		return customizerBuilder(builder)
	}

	companion object {

		@JvmStatic
		fun main(args: Array<String>) {
			customizerBuilder(SpringApplicationBuilder()).run(*args)
		}

		private fun customizerBuilder(builder: SpringApplicationBuilder): SpringApplicationBuilder {
			return builder.sources(MyApplication::class.java).bannerMode(Banner.Mode.OFF)
		}

	}

}

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

  • web.xml のない Servlet 3.0+ アプリケーション。

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

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

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

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

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

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

WebLogic への WAR のデプロイ

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

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

  • Java

  • Kotlin

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 {

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

@SpringBootApplication
class MyApplication : SpringBootServletInitializer(), 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>