Authors

Phillip Webb, Dave Syer, Josh Long, Stéphane Nicoll, Rob Winch, Andy Wilkinson, Marcel Overdijk, Christian Dupuis, Sébastien Deleuze, Michael Simons, VedranPavić, Jay Bryant

Copies of this document may be made for your own use and for distribution to others, provided that you do not charge any fee for such copies and further provided that each copy contains this Copyright Notice, whether distributed in print or electronically.

Part I. Spring Boot Documentation

Part II. Getting Started

Spring Boot is compatible with Apache Maven 3.2 or above. If you do not already have Maven installed, you can follow the instructions at maven.apache.org.

	On many operating systems, Maven can be installed with a package manager. If you use OSX Homebrew, try brew install maven. Ubuntu users can run sudo apt-get install maven. Windows users with Chocolatey can run choco install maven from an elevated (administrator) prompt.

Spring Boot dependencies use the org.springframework.boot groupId. Typically, your Maven POM file inherits from the spring-boot-starter-parent project and declares dependencies to one or more “Starters”. Spring Boot also provides an optional Maven plugin to create executable jars.

The following listing shows a typical pom.xml file:

<?xml version="1.0" encoding="UTF-8"?>

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

	<modelVersion>4.0.0</modelVersion>

	<groupId>com.example</groupId>

	<artifactId>myproject</artifactId>

	<version>0.0.1-SNAPSHOT</version>

	<!-- Inherit defaults from Spring Boot -->

	<parent>

		<groupId>org.springframework.boot</groupId>

		<artifactId>spring-boot-starter-parent</artifactId>

		<version>2.0.0.BUILD-SNAPSHOT</version>

	</parent>

	<!-- Add typical dependencies for a web application -->

	<dependencies>

		<dependency>

			<groupId>org.springframework.boot</groupId>

			<artifactId>spring-boot-starter-web</artifactId>

		</dependency>

	</dependencies>

	<!-- Package as an executable jar -->

	<build>

		<plugins>

			<plugin>

				<groupId>org.springframework.boot</groupId>

				<artifactId>spring-boot-maven-plugin</artifactId>

			</plugin>

		</plugins>

	</build>

	<!-- Add Spring repositories -->

	<!-- (you don't need this if you are using a .RELEASE version) -->

	<repositories>

		<repository>

			<id>spring-snapshots</id>

			<url>http://repo.spring.io/snapshot</url>

			<snapshots><enabled>true</enabled></snapshots>

		</repository>

		<repository>

			<id>spring-milestones</id>

			<url>http://repo.spring.io/milestone</url>

		</repository>

	</repositories>

	<pluginRepositories>

		<pluginRepository>

			<id>spring-snapshots</id>

			<url>http://repo.spring.io/snapshot</url>

		</pluginRepository>

		<pluginRepository>

			<id>spring-milestones</id>

			<url>http://repo.spring.io/milestone</url>

		</pluginRepository>

	</pluginRepositories>

</project>

	The spring-boot-starter-parent is a great way to use Spring Boot, but it might not be suitable all of the time. Sometimes you may need to inherit from a different parent POM, or you might not like our default settings. In those cases, see Section 13.2.2, “Using Spring Boot without the Parent POM” for an alternative solution that uses an import scope.

Spring Boot is compatible with Gradle 4. If you do not already have Gradle installed, you can follow the instructions at www.gradle.org/.

Spring Boot dependencies can be declared by using the org.springframework.boot group. Typically, your project declares dependencies to one or more “Starters”. Spring Boot provides a useful Gradle plugin that can be used to simplify dependency declarations and to create executable jars.

The following example shows a typical build.gradle file:

buildscript {

	repositories {

		jcenter()

		maven { url 'http://repo.spring.io/snapshot' }

		maven { url 'http://repo.spring.io/milestone' }

	}

	dependencies {

		classpath 'org.springframework.boot:spring-boot-gradle-plugin:2.0.0.BUILD-SNAPSHOT'

	}

}

apply plugin: 'java'

apply plugin: 'org.springframework.boot'

apply plugin: 'io.spring.dependency-management'

jar {

	baseName = 'myproject'

	version =  '0.0.1-SNAPSHOT'

}

repositories {

	jcenter()

	maven { url "http://repo.spring.io/snapshot" }

	maven { url "http://repo.spring.io/milestone" }

}

dependencies {

	compile("org.springframework.boot:spring-boot-starter-web")

	testCompile("org.springframework.boot:spring-boot-starter-test")

}

You can download the Spring CLI distribution from the Spring software repository:

Cutting edge snapshot distributions are also available.

Once downloaded, follow the INSTALL.txt instructions from the unpacked archive. In summary, there is a spring script (spring.bat for Windows) in a bin/ directory in the .zip file. Alternatively, you can use java -jar with the .jar file (the script helps you to be sure that the classpath is set correctly).

SDKMAN! (The Software Development Kit Manager) can be used for managing multiple versions of various binary SDKs, including Groovy and the Spring Boot CLI. Get SDKMAN! from sdkman.io and install Spring Boot by using the following commands:

$ sdk install springboot

$ spring --version

Spring Boot v2.0.0.BUILD-SNAPSHOT

If you are developing features for the CLI and want easy access to the version you built, use the following commands:

$ sdk install springboot dev /path/to/spring-boot/spring-boot-cli/target/spring-boot-cli-2.0.0.BUILD-SNAPSHOT-bin/spring-2.0.0.BUILD-SNAPSHOT/

$ sdk default springboot dev

$ spring --version

Spring CLI v2.0.0.BUILD-SNAPSHOT

The preceding instructions install a local instance of spring called the dev instance. It points at your target build location, so every time you rebuild Spring Boot,spring is up-to-date.

You can see it by running the following command:

$ sdk ls springboot

================================================================================

Available Springboot Versions

================================================================================

> + dev

* 2.0.0.BUILD-SNAPSHOT

================================================================================

+ - local version

* - installed

> - currently in use

================================================================================

If you are on a Mac and use Homebrew, you can install the Spring Boot CLI by using the following commands:

$ brew tap pivotal/tap

$ brew install springboot

Homebrew installs spring to /usr/local/bin.

	If you do not see the formula, your installation of brew might be out-of-date. In that case, run brew update and try again.

If you are on a Mac and use MacPorts, you can install the Spring Boot CLI by using the following command:

$ sudo port install spring-boot-cli

The Spring Boot CLI includes scripts that provide command completion for the BASH and zsh shells. You can source the script (also named spring) in any shell or put it in your personal or system-wide bash completion initialization. On a Debian system, the system-wide scripts are in /shell-completion/bash and all scripts in that directory are executed when a new shell starts. For example, to run the script manually if you have installed using SDKMAN!, use the following commands:

$ . ~/.sdkman/candidates/springboot/current/shell-completion/bash/spring

$ spring <HIT TAB HERE>

  grab  help  jar  run  test  version

	If you install the Spring Boot CLI by using Homebrew or MacPorts, the command-line completion scripts are automatically registered with your shell.

You can use the following web application to test your installation. To start, create a file called app.groovy, as follows:

@RestController

class ThisWillActuallyRun {

	@RequestMapping("/")

	String home() {

		"Hello World!"

	}

}

Then run it from a shell, as follows:

$ spring run app.groovy

	The first run of your application is slow, as dependencies are downloaded. Subsequent runs are much quicker.

Open localhost:8080 in your favorite web browser. You should see the following output:

Hello World!

The first annotation on our Example class is @RestController. This is known as a stereotype annotation. It provides hints for people reading the code and for Spring that the class plays a specific role. In this case, our class is a web @Controller, so Spring considers it when handling incoming web requests.

The @RequestMapping annotation provides “routing” information. It tells Spring that any HTTP request with the / path should be mapped to the home method. The@RestController annotation tells Spring to render the resulting string directly back to the caller.

	The @RestController and @RequestMapping annotations are Spring MVC annotations. (They are not specific to Spring Boot.) See the MVC section in the Spring Reference Documentation for more details.

The second class-level annotation is @EnableAutoConfiguration. This annotation tells Spring Boot to “guess” how you want to configure Spring, based on the jar dependencies that you have added. Since spring-boot-starter-web added Tomcat and Spring MVC, the auto-configuration assumes that you are developing a web application and sets up Spring accordingly.

The final part of our application is the main method. This is just a standard method that follows the Java convention for an application entry point. Our main method delegates to Spring Boot’s SpringApplication class by calling run. SpringApplication bootstraps our application, starting Spring, which, in turn, starts the auto-configured Tomcat web server. We need to pass Example.class as an argument to the run method to tell SpringApplication which is the primary Spring component. The args array is also passed through to expose any command-line arguments.

Java does not provide a standard way to load nested jar files (jar files that are themselves contained within a jar). This can be problematic if you are looking to distribute a self-contained application.

To solve this problem, many developers use “uber” jars. An uber jar packages all the classes from all the application’s dependencies into a single archive. The problem with this approach is that it becomes hard to see which libraries are in your application. It can also be problematic if the same filename is used (but with different content) in multiple jars.

Spring Boot takes a different approach and allows you to actually nest jars directly.

Part III. Using Spring Boot

• Java 1.8 as the default compiler level.
• UTF-8 source encoding.
• A Dependency Management section, inherited from the spring-boot-dependencies pom, that manages the versions of common dependencies. This dependency management lets you omit <version> tags for those dependencies when used in your own pom.
• Sensible resource filtering.
• Sensible plugin configuration (exec plugin, Git commit ID, and shade).
• Sensible resource filtering for application.properties and application.yml including profile-specific files (for example, application-foo.properties andapplication-foo.yml)

To configure your project to inherit from the spring-boot-starter-parent set the parent, as follows:

<!-- Inherit defaults from Spring Boot -->

<parent>

	<groupId>org.springframework.boot</groupId>

	<artifactId>spring-boot-starter-parent</artifactId>

	<version>2.0.0.BUILD-SNAPSHOT</version>

</parent>

	You should need to specify only the Spring Boot version number on this dependency. If you import additional starters, you can safely omit the version number.

With that setup, you can also override individual dependencies by overriding a property in your own project. For instance, to upgrade to another Spring Data release train, you would add the following to your pom.xml:

<properties>

	<spring-data-releasetrain.version>Fowler-SR2</spring-data-releasetrain.version>

</properties>

	Check the spring-boot-dependencies pom for a list of supported properties.

Not everyone likes inheriting from the spring-boot-starter-parent POM. You may have your own corporate standard parent that you need to use or you may prefer to explicitly declare all your Maven configuration.

If you do not want to use the spring-boot-starter-parent, you can still keep the benefit of the dependency management (but not the plugin management) by using ascope=import dependency, as follows:

<dependencyManagement>

		<dependencies>

		<dependency>

			<!-- Import dependency management from Spring Boot -->

			<groupId>org.springframework.boot</groupId>

			<artifactId>spring-boot-dependencies</artifactId>

			<version>2.0.0.BUILD-SNAPSHOT</version>

			<type>pom</type>

	        <scope>import</scope>

		</dependency>

	</dependencies>

</dependencyManagement>

The preceding sample setup does not let you override individual dependencies by using a property, as explained above. To achieve the same result, you need to add an entry in the dependencyManagement of your project before the spring-boot-dependencies entry. For instance, to upgrade to another Spring Data release train, you could add the following element to your pom.xml:

<dependencyManagement>

	<dependencies>

		<!-- Override Spring Data release train provided by Spring Boot -->

		<dependency>

			<groupId>org.springframework.data</groupId>

			<artifactId>spring-data-releasetrain</artifactId>

			<version>Fowler-SR2</version>

			<scope>import</scope>

			<type>pom</type>

		</dependency>

		<dependency>

			<groupId>org.springframework.boot</groupId>

			<artifactId>spring-boot-dependencies</artifactId>

			<version>2.0.0.BUILD-SNAPSHOT</version>

			<type>pom</type>

			<scope>import</scope>

		</dependency>

	</dependencies>

</dependencyManagement>

	In the preceding example, we specify a BOM, but any dependency type can be overridden in the same way.

Spring Boot includes a Maven plugin that can package the project as an executable jar. Add the plugin to your <plugins> section if you want to use it, as shown in the following example:

<build>

	<plugins>

		<plugin>

			<groupId>org.springframework.boot</groupId>

			<artifactId>spring-boot-maven-plugin</artifactId>

		</plugin>

	</plugins>

</build>

	If you use the Spring Boot starter parent pom, you need to add only the plugin. There is no need to configure it unless you want to change the settings defined in the parent.

• Reference (HTML and PDF)
• API

All official starters follow a similar naming pattern; spring-boot-starter-*, where * is a particular type of application. This naming structure is intended to help when you need to find a starter. The Maven integration in many IDEs allow you to search dependencies by name. For example, with the appropriate Eclipse or STS plugin installed, you can simply hit ctrl-space in the POM editor and type “spring-boot-starter” for a complete list.

As explained in the “Creating Your Own Starter” section, third party starters should not start with spring-boot, as it is reserved for official Spring Boot artifacts. Rather, a third-party starter typically starts with the name of the project. For example, a third-party starter project called thirdpartyproject would typically be named thirdpartyproject-spring-boot-starter.

Table 13.1. Spring Boot application starters

Table 13.2. Spring Boot production starters

Table 13.3. Spring Boot technical starters

As DevTools monitors classpath resources, the only way to trigger a restart is to update the classpath. The way in which you cause the classpath to be updated depends on the IDE that you are using. In Eclipse, saving a modified file causes the classpath to be updated and triggers a restart. In IntelliJ IDEA, building the project (Build -> Make Project) has the same effect.

The restart technology provided by Spring Boot works by using two classloaders. Classes that do not change (for example, those from third-party jars) are loaded into a base classloader. Classes that you are actively developing are loaded into a restart classloader. When the application is restarted, the restart classloader is thrown away and a new one is created. This approach means that application restarts are typically much faster than “cold starts”, since the base classloader is already available and populated.

If you find that restarts are not quick enough for your applications or you encounter classloading issues, you could consider reloading technologies such as JRebelfrom ZeroTurnaround. These work by  rewriting classes as they are loaded to make them more amenable to reloading.

Certain resources do not necessarily need to trigger a restart when they are changed. For example, Thymeleaf templates can be edited in-place. By default, changing resources in /META-INF/maven, /META-INF/resources, /resources, /static, /public, or /templates does not trigger a restart but does trigger a live reload. If you want to customize these exclusions, you can use the spring.devtools.restart.exclude property. For example, to exclude only /static and /public you would set the following property:

spring.devtools.restart.exclude=static/**,public/**

	If you want to keep those defaults and add additional exclusions, use the spring.devtools.restart.additional-exclude property instead.

You may want your application to be restarted or reloaded when you make changes to files that are not on the classpath. To do so, use thespring.devtools.restart.additional-paths property to configure additional paths to watch for changes. You can use the spring.devtools.restart.excludeproperty described above to control whether changes beneath the additional paths trigger a full restart or a live reload.

If you do not want to use the restart feature, you can disable it by using the spring.devtools.restart.enabled property. In most cases, you can set this property in your application.properties (doing so still initializes the restart classloader, but it does not watch for file changes).

If you need to completely disable restart support (for example, because it doesn’t work with a specific library), you need to set the spring.devtools.restart.enabledSystem property to false before calling SpringApplication.run(…​), as shown in the following example:

public static void main(String[] args) {

	System.setProperty("spring.devtools.restart.enabled", "false");

	SpringApplication.run(MyApp.class, args);

}

If you work with an IDE that continuously compiles changed files, you might prefer to trigger restarts only at specific times. To do so, you can use a “trigger file”, which is a special file that must be modified when you want to actually trigger a restart check. Changing the file only triggers the check and the restart will only occur if Devtools has detected it has to do something. The trigger file can be updated manually or with an IDE plugin.

To use a trigger file, set the spring.devtools.restart.trigger-file property to the path of your trigger file.

	You might want to set spring.devtools.restart.trigger-file as a global setting, so that all your projects behave in the same way.

As described in the Restart vs Reload section above, restart functionality is implemented by using two classloaders. For most applications, this approach works well. However, sometimes it can cause classloading issues.

By default, any open project in your IDE is loaded with the “restart” classloader, and any regular .jar file is loaded with the “base” classloader. If you work on a multi-module project, and not every module is imported into your IDE, you may need to customize things. To do so, you can create a META-INF/spring-devtools.properties file.

The spring-devtools.properties file can contain properties prefixed with restart.exclude and restart.include. The include elements are items that should be pulled up into the “restart” classloader, and the exclude elements are items that should be pushed down into the “base” classloader. The value of the property is a regex pattern that is applied to the classpath, as shown in the following example:

restart.exclude.companycommonlibs=/mycorp-common-[\\w-]+\.jar

restart.include.projectcommon=/mycorp-myproj-[\\w-]+\.jar

	All property keys must be unique. As long as a property starts with restart.include. or restart.exclude. it is considered.

	All META-INF/spring-devtools.properties from the classpath will be loaded. You can package files inside your project, or in the libraries that the project consumes.

Restart functionality does not work well with objects that are deserialized by using a standard ObjectInputStream. If you need to deserialize data, you may need to use Spring’s ConfigurableObjectInputStream in combination with Thread.currentThread().getContextClassLoader().

Unfortunately, several third-party libraries deserialize without considering the context classloader. If you find such a problem, you need to request a fix with the original authors.

The remote client application is designed to be run from within your IDE. You need to run org.springframework.boot.devtools.RemoteSpringApplication with the same classpath as the remote project that you connect to. The application’s single required argument is the remote URL to which it connects.

For example, if you are using Eclipse or STS and you have a project named my-app that you have deployed to Cloud Foundry, you would do the following:

A running remote client might resemble the following listing:

  .   ____          _                                              __ _ _

 /\\ / ___'_ __ _ _(_)_ __  __ _          ___               _      \ \ \ \

( ( )\___ | '_ | '_| | '_ \/ _` |        | _ \___ _ __  ___| |_ ___ \ \ \ \

 \\/  ___)| |_)| | | | | || (_| []::::::[]   / -_) '  \/ _ \  _/ -_) ) ) ) )

  '  |____| .__|_| |_|_| |_\__, |        |_|_\___|_|_|_\___/\__\___|/ / / /

 =========|_|==============|___/===================================/_/_/_/

 :: Spring Boot Remote :: 2.0.0.BUILD-SNAPSHOT

2015-06-10 18:25:06.632  INFO 14938 --- [           main] o.s.b.devtools.RemoteSpringApplication   : Starting RemoteSpringApplication on pwmbp with PID 14938 (/Users/pwebb/projects/spring-boot/code/spring-boot-devtools/target/classes started by pwebb in /Users/pwebb/projects/spring-boot/code/spring-boot-samples/spring-boot-sample-devtools)

2015-06-10 18:25:06.671  INFO 14938 --- [           main] s.c.a.AnnotationConfigApplicationContext : Refreshing org.springframework.context.annotation.AnnotationConfigApplicationContext@2a17b7b6: startup date [Wed Jun 10 18:25:06 PDT 2015]; root of context hierarchy

2015-06-10 18:25:07.043  WARN 14938 --- [           main] o.s.b.d.r.c.RemoteClientConfiguration    : The connection to http://localhost:8080 is insecure. You should use a URL starting with 'https://'.

2015-06-10 18:25:07.074  INFO 14938 --- [           main] o.s.b.d.a.OptionalLiveReloadServer       : LiveReload server is running on port 35729

2015-06-10 18:25:07.130  INFO 14938 --- [           main] o.s.b.devtools.RemoteSpringApplication   : Started RemoteSpringApplication in 0.74 seconds (JVM running for 1.105)

	Because the remote client is using the same classpath as the real application it can directly read application properties. This is how the spring.devtools.remote.secret property is read and passed to the server for authentication.

	It is always advisable to use https:// as the connection protocol, so that traffic is encrypted and passwords cannot be intercepted.

	If you need to use a proxy to access the remote application, configure the spring.devtools.remote.proxy.host and spring.devtools.remote.proxy.port properties.

The remote client monitors your application classpath for changes in the same way as the local restart. Any updated resource is pushed to the remote application and (if required) triggers a restart. This can be helpful if you iterate on a feature that uses a cloud service that you do not have locally. Generally, remote updates and restarts are much quicker than a full rebuild and deploy cycle.

	Files are only monitored when the remote client is running. If you change a file before starting the remote client, it is not pushed to the remote server.

Part IV. Spring Boot features

Table 23.1. Banner variables

1. An ApplicationStartingEvent is sent at the start of a run but before any processing except the registration of listeners and initializers.
2. An ApplicationEnvironmentPreparedEvent is sent when the Environment to be used in the context is known but before the context is created.
3. An ApplicationPreparedEvent is sent just before the refresh is started but after bean definitions have been loaded.
4. An ApplicationReadyEvent is sent after the refresh and any related callbacks have been processed, to indicate that the application is ready to service requests.
5. An ApplicationFailedEvent is sent if there is an exception on startup.

1. A /config subdirectory of the current directory.
2. The current directory
3. A classpath /config package
4. The classpath root

1. file:./config/
2. file:./
3. classpath:/config/
4. classpath:/

1. file:./custom-config/
2. classpath:custom-config/

1. file:./custom-config/
2. classpath:custom-config/
3. file:./config/
4. file:./
5. classpath:/config/
6. classpath:/

Spring Framework provides two convenient classes that can be used to load YAML documents. The YamlPropertiesFactoryBean loads YAML as Properties and the YamlMapFactoryBean loads YAML as a Map.

For example, consider the following YAML document:

environments:

	dev:

		url: http://dev.bar.com

		name: Developer Setup

	prod:

		url: http://foo.bar.com

		name: My Cool App

The preceding example would be transformed into the following properties:

environments.dev.url=http://dev.bar.com

environments.dev.name=Developer Setup

environments.prod.url=http://foo.bar.com

environments.prod.name=My Cool App

YAML lists are represented as property keys with [index] dereferencers. For example, consider the following YAML:

my:

servers:

	- dev.bar.com

	- foo.bar.com

The preceding example would be transformed into these properties:

my.servers[0]=dev.bar.com

my.servers[1]=foo.bar.com

To bind to properties like that by using the Spring DataBinder utilities (which is what @ConfigurationProperties does), you need to have a property in the target bean of type java.util.List (or Set) and you either need to provide a setter or initialize it with a mutable value. For example, the following example binds to the properties shown previously:

@ConfigurationProperties(prefix="my")

public class Config {

	private List<String> servers = new ArrayList<String>();

	public List<String> getServers() {

		return this.servers;

	}

}

	When lists are configured in more than one place, overriding works by replacing the entire list. In the preceding example, when my.servers is redefined in several places, the entire list from the PropertySource with higher precedence will override any other configuration for that list. Both comma-separated lists and yaml lists can be used for completely overriding the contents of the list.

The YamlPropertySourceLoader class can be used to expose YAML as a PropertySource in the Spring Environment. Doing so lets you use the @Valueannotation with placeholders syntax to access YAML properties.

You can specify multiple profile-specific YAML documents in a single file by using a spring.profiles key to indicate when the document applies, as shown in the following example:

server:

	address: 192.168.1.100

---

spring:

	profiles: development

server:

	address: 127.0.0.1

---

spring:

	profiles: production

server:

	address: 192.168.1.120

In the preceding example, if the development profile is active, the server.address property is 127.0.0.1. Similarly, if the production profile is active, theserver.address property is 192.168.1.120. If the development and production profiles are not enabled, then the value for the property is 192.168.1.100.

If none are explicitly active when the application context starts, the default profiles are activated . So, in the following YAML, we set a value for security.user.password that is only available in the "default" profile:

server:

  port: 8000

---

spring:

  profiles: default

security:

  user:

    password: weak

Whereas, in the following example, the password is always set because it is not attached to any profile, and it would have to be explicitly reset in all other profiles as necessary:

server:

  port: 8000

security:

  user:

    password: weak

Spring profiles designated by using the "spring.profiles" element may optionally be negated by using the ! character. If both negated and non-negated profiles are specified for a single document, at least one non-negated profile must match, and no negated profiles may match.

YAML files cannot be loaded by using the @PropertySource annotation. So, in the case that you need to load values that way, you need to use a properties file.

As we have seen above, any YAML content is ultimately transformed to properties. That process may be counter-intuitive when overriding “list” properties through a profile.

For example, assume a MyPojo object with name and description attributes that are null by default. The following example exposes a list of MyPojo from FooProperties:

@ConfigurationProperties("foo")

public class FooProperties {

	private final List<MyPojo> list = new ArrayList<>();

	public List<MyPojo> getList() {

		return this.list;

	}

}

Consider the following configuration:

foo:

  list:

    - name: my name

      description: my description

---

spring:

  profiles: dev

foo:

  list:

       - name: my another name

If the dev profile is not active, FooProperties.list contains one MyPojo entry as defined above. If the dev profile is enabled however, the list still contains only one entry (with a name of “my another name” and a description of null). This configuration does not add a second MyPojo instance to the list, and it does not merge the items.

When a collection is specified in multiple profiles, the one with the highest priority (and only that one) is used:

foo:

  list:

	- name: my name

	  description: my description

	- name: another name

	  description: another description

---

spring:

  profiles: dev

foo:

  list:

	 - name: my another name

In the preceding example, if the dev profile is active, FooProperties.list contains one MyPojo entry (with a name of “my another name” and a description of null).

• foo.enabled, false by default.
• foo.remote-address, with a type that can be coerced from String.
• foo.security.username, with a nested "security" object whose name is determined by the name of the property. In particular, the return type is not used at all there and could have been SecurityProperties.
• foo.security.password.
• foo.security.roles, with a collection of String.

As well as using @ConfigurationProperties to annotate a class, you can also use it on public @Bean methods. Doing so can be particularly useful when you want to bind properties to third-party components that are outside of your control.

To configure a bean from the Environment properties, add @ConfigurationProperties to its bean registration, as shown in the following example:

@ConfigurationProperties(prefix = "bar")
@Bean

public BarComponent barComponent() {

	...

}

Any property defined with the bar prefix is mapped onto that BarComponent bean in a similar manner as the preceding FooProperties example.

Spring Boot uses some relaxed rules for binding Environment properties to @ConfigurationProperties beans, so there does not need to be an exact match between the Environment property name and the bean property name. Common examples where this is useful include dash-separated environment properties (for example, context-path binds to contextPath), and capitalized environment properties (for example, PORT binds to port).

For example, consider the following @ConfigurationProperties class:

@ConfigurationProperties(prefix="person")

public class OwnerProperties {

	private String firstName;

	public String getFirstName() {

		return this.firstName;

	}

	public void setFirstName(String firstName) {

		this.firstName = firstName;

	}

}

In the preceding example, the following properties names can all be used:

	The prefix value for the annotation must be in kebab case (lowercase and separated by -, such as kebab-case).

	We recommend that, when possible, properties are stored in lower-case kebab format, such as my.property-name=foo.

Spring attempts to coerce the external application properties to the right type when it binds to the @ConfigurationProperties beans. If you need custom type conversion, you can provide a ConversionService bean (with bean named conversionService) or custom property editors (through a CustomEditorConfigurerbean) or custom Converters (with bean definitions annotated as @ConfigurationPropertiesBinding).

As this bean is requested very early during the application lifecycle, make sure to limit the dependencies that your ConversionService is using. Typically, any dependency that you require may not be fully initialized at creation time. You may want to rename your custom ConversionService if it is not required for configuration keys coercion and only rely on custom converters qualified with @ConfigurationPropertiesBinding.

Spring Boot attempts to validate @ConfigurationProperties classes whenever they are annotated with Spring’s @Validated annotation. You can use JSR-303 javax.validation constraint annotations directly on your configuration class. To do so, ensure that a compliant JSR-303 implementation is on your classpath and then add constraint annotations to your fields, as shown in the following example:

@ConfigurationProperties(prefix="foo")
@Validated

public class FooProperties {

	@NotNull

	private InetAddress remoteAddress;

	// ... getters and setters

}

In order to validate the values of nested properties, you must annotate the associated field as @Valid to trigger its validation. The following example builds on the preceding FooProperties example:

@ConfigurationProperties(prefix="connection")
@Validated

public class FooProperties {

	@NotNull

	private InetAddress remoteAddress;

	@Valid

	private final Security security = new Security();

	// ... getters and setters

	public static class Security {

		@NotEmpty

		public String username;

		// ... getters and setters

	}

}

You can also add a custom Spring Validator by creating a bean definition called configurationPropertiesValidator. The @Bean method should be declared static. The configuration properties validator is created very early in the application’s lifecycle, and declaring the @Bean method as static lets the bean be created without having to instantiate the @Configuration class. Doing so avoids any problems that may be caused by early instantiation. There is a property validation sample that shows how to set things up.

	The spring-boot-actuator module includes an endpoint that exposes all @ConfigurationProperties beans. Point your web browser to/application/configprops or use the equivalent JMX endpoint. See the "Production ready features" section for details.

The @Value annotation is a core container feature, and it does not provide the same features as type-safe configuration properties. The following table summarizes the features that are supported by @ConfigurationProperties and @Value:

If you define a set of configuration keys for your own components, we recommend you to group them in a POJO annotated with @ConfigurationProperties. You should also be aware that, since @Value does not support relaxed binding, it is not a good candidate if you need to provide the value by using environment variables.

Finally, while you can write a SpEL expression in @Value, such expressions are not processed from Application property files.

• Date and Time — Millisecond precision and easily sortable.
• Log Level — ERROR, WARN, INFO, DEBUG, or TRACE.
• Process ID.
• A --- separator to distinguish the start of actual log messages.
• Thread name — Enclosed in square brackets (may be truncated for console output).
• Logger name — This is usually the source class name (often abbreviated).
• The log message.

If your terminal supports ANSI, color output is used to aid readability. You can set spring.output.ansi.enabled to a supported value to override the auto detection.

Color coding is configured by using the %clr conversion word. In its simplest form the converter colors the output according to the log level, as shown in the following example:

%clr(%5p)

The mapping of log level to a color is as follows:

Alternatively, you can specify the color or style that should be used by providing it as an option to the conversion. For example, to make the text yellow, use the following setting:

%clr(%d{yyyy-MM-dd HH:mm:ss.SSS}){yellow}

The following colors and styles are supported:

Table 26.1. Logging properties

• Logback
• Log4j 2
• Java Util logging

The <springProfile> tag lets you optionally include or exclude sections of configuration based on the active Spring profiles. Profile sections are supported anywhere within the <configuration> element. Use the name attribute to specify which profile accepts the configuration. Multiple profiles can be specified using a comma-separated list. The following listing shows three sample profiles:

<springProfile name="staging">

	<!-- configuration to be enabled when the "staging" profile is active -->

</springProfile>

<springProfile name="dev, staging">

	<!-- configuration to be enabled when the "dev" or "staging" profiles are active -->

</springProfile>

<springProfile name="!production">

	<!-- configuration to be enabled when the "production" profile is not active -->

</springProfile>

The <springProperty> tag lets you expose properties from the Spring Environment for use within Logback. Doing so can be useful if you want to access values from your application.properties file in your Logback configuration. The tag works in a similar way to Logback’s standard <property> tag. However, rather than specifying a direct value, you specify the source of the property (from the Environment). If you need to store the property somewhere other than in local scope, you can use the scope attribute. If you need a fallback value (in case the property is not set in the Environment), you can use the defaultValue attribute.

<springProperty scope="context" name="fluentHost" source="myapp.fluentd.host"

		defaultValue="localhost"/>

<appender name="FLUENT" class="ch.qos.logback.more.appenders.DataFluentAppender">

	<remoteHost>${fluentHost}</remoteHost>

	...

</appender>

	The source must be specified using kebab case (such as my.property-name). However, properties can be added to the Environment by using the relaxed rules.

Spring Boot provides auto-configuration for Spring MVC that works well with most applications.

The auto-configuration adds the following features on top of Spring’s defaults:

If you want to keep Spring Boot MVC features and you want to add additional MVC configuration (interceptors, formatters, view controllers, and other features), you can add your own @Configuration class of type WebMvcConfigurer but without @EnableWebMvc. If you wish to provide custom instances of RequestMappingHandlerMapping, RequestMappingHandlerAdapter, or ExceptionHandlerExceptionResolver, you can declare a WebMvcRegistrationsAdapter instance to provide such components.

If you want to take complete control of Spring MVC, you can add your own @Configuration annotated with @EnableWebMvc.

Spring MVC uses the HttpMessageConverter interface to convert HTTP requests and responses. Sensible defaults are included out of the box. For example, objects can be automatically converted to JSON (by using the Jackson library) or XML (by using the Jackson XML extension, if available, or by using JAXB if the Jackson XML extension is not available). By default, strings are encoded in UTF-8.

If you need to add or customize converters, you can use Spring Boot’s HttpMessageConverters class:

import org.springframework.boot.autoconfigure.web.HttpMessageConverters;

import org.springframework.context.annotation.*;

import org.springframework.http.converter.*;

@Configuration

public class MyConfiguration {

	@Bean

	public HttpMessageConverters customConverters() {

		HttpMessageConverter<?> additional = ...

		HttpMessageConverter<?> another = ...

		return new HttpMessageConverters(additional, another);

	}

}

Any HttpMessageConverter bean that is present in the context is added to the list of converters. You can also override default converters in the same way.

If you use Jackson to serialize and deserialize JSON data, you might want to write your own JsonSerializer and JsonDeserializer classes. Custom serializers are usually registered with Jackson through a module, but Spring Boot provides an alternative @JsonComponent annotation that makes it easier to directly register Spring Beans.

You can use the @JsonComponent annotation directly on JsonSerializer or JsonDeserializer implementations. You can also use it on classes that contains serializers/deserializers as inner-classes, as shown in the following example:

import java.io.*;

import com.fasterxml.jackson.core.*;

import com.fasterxml.jackson.databind.*;

import org.springframework.boot.jackson.*;

@JsonComponent

public class Example {

	public static class Serializer extends JsonSerializer<SomeObject> {

		// ...

	}

	public static class Deserializer extends JsonDeserializer<SomeObject> {

		// ...

	}

}

All @JsonComponent beans in the ApplicationContext are automatically registered with Jackson. Because @JsonComponent is meta-annotated with @Component, the usual component-scanning rules apply.

Spring Boot also provides JsonObjectSerializer and JsonObjectDeserializer base classes that provide useful alternatives to the standard Jackson versions when serializing objects. See JsonObjectSerializer and JsonObjectDeserializer in the Javadoc for details.

Spring MVC has a strategy for generating error codes for rendering error messages from binding errors: MessageCodesResolver. If you set thespring.mvc.message-codes-resolver.format property PREFIX_ERROR_CODE or POSTFIX_ERROR_CODE, Spring Boot creates one for you (see the enumeration inDefaultMessageCodesResolver.Format).

By default, Spring Boot serves static content from a directory called /static (or /public or /resources or /META-INF/resources) in the classpath or from the root of the ServletContext. It uses the ResourceHttpRequestHandler from Spring MVC so that you can modify that behavior by adding your own WebMvcConfigurerand overriding the addResourceHandlers method.

In a stand-alone web application, the default servlet from the container is also enabled and acts as a fallback, serving content from the root of the ServletContext if Spring decides not to handle it. Most of the time, this will not happen (unless you modify the default MVC configuration) because Spring can always handle requests through the DispatcherServlet.

By default, resources are mapped on /**, but you can tune that with the spring.mvc.static-path-pattern property. For instance, relocating all resources to/resources/** can be achieved as follows:

spring.mvc.static-path-pattern=/resources/**

You can also customize the static resource locations by using the spring.resources.static-locations property (replacing the default values with a list of directory locations). The root Servlet context path "/" is automatically added as a location as well. If you do this, the default welcome page detection switches to your custom locations. So, if there is an index.html in any of your locations on startup, it is the home page of the application.

In addition to the ‘standard’ static resource locations mentioned earlier, a special case is made for Webjars content. Any resources with a path in /webjars/** are served from jar files if they are packaged in the Webjars format.

	Do not use the src/main/webapp directory if your application is packaged as a jar. Although this directory is a common standard, it works only with war packaging, and it is silently ignored by most build tools if you generate a jar.

Spring Boot also supports the advanced resource handling features provided by Spring MVC, allowing use cases such as cache-busting static resources or using version agnostic URLs for Webjars.

To use version agnostic URLs for Webjars, add the webjars-locator dependency. Then declare your Webjar. Using jQuery as an example, adding"/webjars/jquery/dist/jquery.min.js" results in "/webjars/jquery/x.y.z/dist/jquery.min.js". where x.y.z is the Webjar version.

	If you are using JBoss, you need to declare the webjars-locator-jboss-vfs dependency instead of the webjars-locator. Otherwise, all Webjars resolve as a 404.

To use cache busting, the following configuration configures a cache busting solution for all static resources, effectively adding a content hash, such as<link href="/css/spring-2a2d595e6ed9a0b24f027f2b63b134d6.css"/>, in URLs:

spring.resources.chain.strategy.content.enabled=true

spring.resources.chain.strategy.content.paths=/**

	Links to resources are rewritten in templates at runtime, thanks to a ResourceUrlEncodingFilter that is auto-configured for Thymeleaf and FreeMarker. You should manually declare this filter when using JSPs. Other template engines are currently not automatically supported but can be with custom template macros/helpers and the use of the ResourceUrlProvider.

When loading resources dynamically with, for example, a JavaScript module loader, renaming files is not an option. That is why other strategies are also supported and can be combined. A "fixed" strategy adds a static version string in the URL without changing the file name, as shown in the following example:

spring.resources.chain.strategy.content.enabled=true

spring.resources.chain.strategy.content.paths=/**

spring.resources.chain.strategy.fixed.enabled=true

spring.resources.chain.strategy.fixed.paths=/js/lib/

spring.resources.chain.strategy.fixed.version=v12

With this configuration, JavaScript modules located under "/js/lib/" use a fixed versioning strategy ("/v12/js/lib/mymodule.js"), while other resources still use the content one (<link href="/css/spring-2a2d595e6ed9a0b24f027f2b63b134d6.css"/>).

See ResourceProperties for more of the supported options.

	This feature has been thoroughly described in a dedicated blog post and in Spring Framework’s reference documentation.

Spring Boot looks for a favicon.ico in the configured static content locations and the root of the classpath (in that order). If such a file is present, it is automatically used as the favicon of the application.

Spring MVC uses a WebBindingInitializer to initialize a WebDataBinder for a particular request. If you create your own ConfigurableWebBindingInitializer@Bean, Spring Boot automatically configures Spring MVC to use it.

As well as REST web services, you can also use Spring MVC to serve dynamic HTML content. Spring MVC supports a variety of templating technologies, including Thymeleaf, FreeMarker, and JSPs. Also, many other templating engines include their own Spring MVC integrations.

Spring Boot includes auto-configuration support for the following templating engines:

	If possible, JSPs should be avoided. There are several known limitations when using them with embedded servlet containers.

When you use one of these templating engines with the default configuration, your templates are picked up automatically from src/main/resources/templates.

Depending on how you run your application, IntelliJ IDEA orders the classpath differently. Running your application in the IDE from its main method results in a different ordering than when you run your application by using Maven or Gradle or from its packaged jar. This can cause Spring Boot to fail to find the templates on the classpath. If you have this problem, you can reorder the classpath in the IDE to place the module’s classes and resources first. Alternatively, you can configure the template prefix to search every templates directory on the classpath, as follows: classpath*:/templates/.

By default, Spring Boot provides an /error mapping that handles all errors in a sensible way, and it is registered as a ‘global’ error page in the servlet container. For machine clients, it produces a JSON response with details of the error, the HTTP status, and the exception message. For browser clients, there is a ‘whitelabel’ error view that renders the same data in HTML format (to customize it, add a View that resolves to ‘error’). To replace the default behavior completely, you can implementErrorController and register a bean definition of that type or add a bean of type ErrorAttributes to use the existing mechanism but replace the contents.

The BasicErrorController can be used as a base class for a custom ErrorController. This is particularly useful if you want to add a handler for a new content type (the default is to handle text/html specifically and provide a fallback for everything else). To do so, extend BasicErrorController, add a public method with a @RequestMapping that has a produces attribute, and create a bean of your new type.

You can also define a class annotated with @ControllerAdvice to customize the JSON document to return for a particular controller and/or exception type, as shown in the following example:

@ControllerAdvice(basePackageClasses = FooController.class)

public class FooControllerAdvice extends ResponseEntityExceptionHandler {

	@ExceptionHandler(YourException.class)
@ResponseBody

	ResponseEntity<?> handleControllerException(HttpServletRequest request, Throwable ex) {

		HttpStatus status = getStatus(request);

		return new ResponseEntity<>(new CustomErrorType(status.value(), ex.getMessage()), status);

	}

	private HttpStatus getStatus(HttpServletRequest request) {

		Integer statusCode = (Integer) request.getAttribute("javax.servlet.error.status_code");

		if (statusCode == null) {

			return HttpStatus.INTERNAL_SERVER_ERROR;

		}

		return HttpStatus.valueOf(statusCode);

	}

}

In the preceding example, if YourException is thrown by a controller defined in the same package as FooController, a JSON representation of the CustomErrorType POJO is used instead of the ErrorAttributes representation.

src/

 +- main/

     +- java/

     |   + <source code>

     +- resources/

         +- public/

             +- error/

             |   +- 404.html

             +- <other public assets>

src/

 +- main/

     +- java/

     |   + <source code>

     +- resources/

         +- templates/

             +- error/

             |   +- 5xx.ftl

             +- <other templates>

public class MyErrorViewResolver implements ErrorViewResolver {

	@Override

	public ModelAndView resolveErrorView(HttpServletRequest request,

			HttpStatus status, Map<String, Object> model) {

		// Use the request or status to optionally return a ModelAndView

		return ...

	}

}

Mapping Error Pages outside of Spring MVC

For applications that do not use Spring MVC, you can use the ErrorPageRegistrar interface to directly register ErrorPages. This abstraction works directly with the underlying embedded servlet container and works even if you do not have a Spring MVC DispatcherServlet.

@Bean

public ErrorPageRegistrar errorPageRegistrar(){

	return new MyErrorPageRegistrar();

}

// ...

private static class MyErrorPageRegistrar implements ErrorPageRegistrar {

	@Override

	public void registerErrorPages(ErrorPageRegistry registry) {

		registry.addErrorPages(new ErrorPage(HttpStatus.BAD_REQUEST, "/400"));

	}

}

	If you register an ErrorPage with a path that ends up being handled by a Filter (as is common with some non-Spring web frameworks, like Jersey and Wicket), then the Filter has to be explicitly registered as an ERROR dispatcher, as shown in the following example:

@Bean

public FilterRegistrationBean myFilter() {

	FilterRegistrationBean registration = new FilterRegistrationBean();

	registration.setFilter(new MyFilter());

	...

	registration.setDispatcherTypes(EnumSet.allOf(DispatcherType.class));

	return registration;

}

Note that the default FilterRegistrationBean does not include the ERROR dispatcher type.

If you develop a RESTful API that makes use of hypermedia, Spring Boot provides auto-configuration for Spring HATEOAS that works well with most applications. The auto-configuration replaces the need to use @EnableHypermediaSupport and registers a number of beans to ease building hypermedia-based applications, including aLinkDiscoverers (for client side support) and an ObjectMapper configured to correctly marshal responses into the desired representation. The ObjectMapper is customized by setting the various spring.jackson.* properties or, if one exists, by a Jackson2ObjectMapperBuilder bean.

You can take control of Spring HATEOAS’s configuration by using @EnableHypermediaSupport. Note that this disables the ObjectMapper customization described earlier.

Cross-origin resource sharing (CORS) is a W3C specification implemented by most browsers that allows you to specify in a flexible way what kind of cross-domain requests are authorized, instead of using some less secure and less powerful approaches such as IFRAME or JSONP.

As of version 4.2, Spring MVC supports CORS. Using controller method CORS configuration with @CrossOrigin annotations in your Spring Boot application does not require any specific configuration. Global CORS configuration can be defined by registering a WebMvcConfigurer bean with a customizedaddCorsMappings(CorsRegistry) method, as shown in the following example:

@Configuration

public class MyConfiguration {

	@Bean

	public WebMvcConfigurer corsConfigurer() {

		return new WebMvcConfigurer() {
@Override

			public void addCorsMappings(CorsRegistry registry) {

				registry.addMapping("/api/**");

			}

		};

	}

}

Spring Boot provides auto-configuration for Spring WebFlux that works well with most applications.

The auto-configuration adds the following features on top of Spring’s defaults:

If you want to keep Spring Boot WebFlux features and you want to add additional WebFlux configuration, you can add your own @Configuration class of type WebFluxConfigurer but without @EnableWebFlux.

If you want to take complete control of Spring WebFlux, you can add your own @Configuration annotated with @EnableWebFlux.

Spring WebFlux uses the HttpMessageReader and HttpMessageWriter interfaces to convert HTTP requests and responses. They are configured with CodecConfigurer to have sensible defaults by looking at the libraries available in your classpath.

Spring Boot applies further customization by using CodecCustomizer instances. For example, spring.jackson.* configuration keys are applied to the Jackson codec.

If you need to add or customize codecs, you can create a custom CodecCustomizer component, as shown in the following example:

import org.springframework.boot.web.codec.CodecCustomizer;

@Configuration

public class MyConfiguration {

	@Bean

	public CodecCustomizer myCodecCustomizer() {

		return codecConfigurer -> {

			// ...

		}

	}

}

You can also leverage Boot’s custom JSON serializers and deserializers.

By default, Spring Boot serves static content from a directory called /static (or /public or /resources or /META-INF/resources) in the classpath. It uses theResourceWebHandler from Spring WebFlux so that you can modify that behavior by adding your own WebFluxConfigurer and overriding the addResourceHandlersmethod.

By default, resources are mapped on /**, but you can tune that by setting the spring.webflux.static-path-pattern property. For instance, relocating all resources to /resources/** can be achieved as follows:

spring.webflux.static-path-pattern=/resources/**

You can also customize the static resource locations by using spring.resources.static-locations. Doing so replaces the default values with a list of directory locations. If you do so, the default welcome page detection switches to your custom locations. So, if there is an index.html in any of your locations on startup, it is the home page of the application.

In addition to the ‘standard’ static resource locations listed earlier, a special case is made for Webjars content. Any resources with a path in /webjars/** are served from jar files if they are packaged in the Webjars format.

	Spring WebFlux applications do not strictly depend on the Servlet API, so they cannot be deployed as war files and do not use the src/main/webappdirectory.

As well as REST web services, you can also use Spring WebFlux to serve dynamic HTML content. Spring WebFlux supports a variety of templating technologies, including Thymeleaf, FreeMarker, and Mustache.

Spring Boot includes auto-configuration support for the following templating engines:

When you use one of these templating engines with the default configuration, your templates are picked up automatically from src/main/resources/templates.

Spring Boot provides a WebExceptionHandler that handles all errors in a sensible way. Its position in the processing order is immediately before the handlers provided by WebFlux, which are considered last. For machine clients it will produce a JSON response with details of the error, the HTTP status and the exception message. For browser clients there is a ‘whitelabel’ error handler that renders the same data in HTML format. You can also provide your own HTML templates to display errors (see thenext section).

The first step to customizing this feature is often about using the existing mechanism but replacing or augmenting the error contents. For that, you can simply add a bean of type ErrorAttributes.

To change the error handling behavior, you can implement ErrorWebExceptionHandler and register a bean definition of that type. Because a WebExceptionHandleris quite low-level, Spring Boot also provides a convenient AbstractErrorWebExceptionHandler to let you handle errors in a WebFlux functional way, as shown in the following example:

public class CustomErrorWebExceptionHandler extends AbstractErrorWebExceptionHandler {

	// Define constructor here

	@Override

	protected RouterFunction<ServerResponse> getRoutingFunction(ErrorAttributes errorAttributes) {

		return RouterFunctions

				.route(aPredicate, aHandler)

				.andRoute(anotherPredicate, anotherHandler);

	}

}

For a more complete picture, you can also subclass DefaultErrorWebExceptionHandler directly and override specific methods.

src/

 +- main/

     +- java/

     |   + <source code>

     +- resources/

         +- public/

             +- error/

             |   +- 404.html

             +- <other public assets>

src/

 +- main/

     +- java/

     |   + <source code>

     +- resources/

         +- templates/

             +- error/

             |   +- 5xx.mustache

             +- <other templates>

When using an embedded servlet container, you can register servlets, filters, and all the listeners (such as HttpSessionListener) from the Servlet spec, either by using Spring beans or by scanning for Servlet components.

Embedded servlet containers do not directly execute the Servlet 3.0+ javax.servlet.ServletContainerInitializer interface or Spring’sorg.springframework.web.WebApplicationInitializer interface. This is an intentional design decision intended to reduce the risk that third party libraries designed to run inside a war may break Spring Boot applications.

If you need to perform servlet context initialization in a Spring Boot application, you should register a bean that implements theorg.springframework.boot.web.servlet.ServletContextInitializer interface. The single onStartup method provides access to the ServletContext and, if necessary, can easily be used as an adapter to an existing WebApplicationInitializer.

Scanning for Servlets, Filters, and listeners

When using an embedded container, automatic registration of @WebServlet, @WebFilter, and @WebListener annotated classes can be enabled by using @ServletComponentScan.

	@ServletComponentScan has no effect in a standalone container, where the container’s built-in discovery mechanisms are used instead.

Under the hood, Spring Boot uses a new type of ApplicationContext for embedded servlet container support. The ServletWebServerApplicationContext is a special type of WebApplicationContext that bootstraps itself by searching for a single ServletWebServerFactory bean. Usually a TomcatServletWebServerFactory, JettyServletWebServerFactory, or UndertowServletWebServerFactory has been auto-configured.

	You usually do not need to be aware of these implementation classes. Most applications are auto-configured, and the appropriate ApplicationContextand ServletWebServerFactory are created on your behalf.

Common servlet container settings can be configured by using Spring Environment properties. Usually, you would define the properties in your application.properties file.

Common server settings include:

Spring Boot tries as much as possible to expose common settings, but this is not always possible. For those cases, dedicated namespaces offer server-specific customizations (see server.tomcat and server.undertow). For instance, access logs can be configured with specific features of the embedded servlet container.

	See the ServerProperties class for a complete list.

import org.springframework.boot.web.server.WebServerFactoryCustomizer;

import org.springframework.boot.web.servlet.server.ConfigurableServletWebServerFactory;

import org.springframework.stereotype.Component;

@Component

public class CustomizationBean implements WebServerFactoryCustomizer<ConfigurableServletWebServerFactory> {

	@Override

	public void customize(ConfigurableServletWebServerFactory server) {

		server.setPort(9000);

	}

}

@Bean

public ConfigurableServletWebServerFactory webServerFactory() {

	TomcatServletWebServerFactory factory = new TomcatServletWebServerFactory();

	factory.setPort(9000);

	factory.setSessionTimeout(10, TimeUnit.MINUTES);

	factory.addErrorPages(new ErrorPage(HttpStatus.NOT_FOUND, "/notfound.html"));

	return factory;

}

When running a Spring Boot application that uses an embedded servlet container (and is packaged as an executable archive), there are some limitations in the JSP support.

There is a JSP sample so that you can see how to set things up.

If you have spring-security-oauth2-client on your classpath, you can take advantage of some auto-configuration to make it easy to set up an OAuth2 Client. This configuration makes use of the properties under OAuth2ClientProperties.

You can register multiple OAuth2 clients and providers under the spring.security.oauth2.client prefix, as shown in the following example:

spring.security.oauth2.client.registration.my-client-1.client-id=abcd

spring.security.oauth2.client.registration.my-client-1.client-secret=password

spring.security.oauth2.client.registration.my-client-1.client-name=Client for user scope

spring.security.oauth2.client.registration.my-client-1.provider=my-oauth-provider

spring.security.oauth2.client.registration.my-client-1.scope=user

spring.security.oauth2.client.registration.my-client-1.redirect-uri-template=http://my-redirect-uri.com

spring.security.oauth2.client.registration.my-client-1.client-authentication-method=basic

spring.security.oauth2.client.registration.my-client-1.authorization-grant-type=authorization_code

spring.security.oauth2.client.registration.my-client-2.client-id=abcd

spring.security.oauth2.client.registration.my-client-2.client-secret=password

spring.security.oauth2.client.registration.my-client-2.client-name=Client for email scope

spring.security.oauth2.client.registration.my-client-2.provider=my-oauth-provider

spring.security.oauth2.client.registration.my-client-2.scope=email

spring.security.oauth2.client.registration.my-client-2.redirect-uri-template=http://my-redirect-uri.com

spring.security.oauth2.client.registration.my-client-2.client-authentication-method=basic

spring.security.oauth2.client.registration.my-client-2.authorization-grant-type=authorization_code

spring.security.oauth2.client.provider.my-oauth-provider.authorization-uri=http://my-auth-server/oauth/authorize

spring.security.oauth2.client.provider.my-oauth-provider.token-uri=http://my-auth-server/oauth/token

spring.security.oauth2.client.provider.my-oauth-provider.user-info-uri=http://my-auth-server/userinfo

spring.security.oauth2.client.provider.my-oauth-provider.jwk-set-uri=http://my-auth-server/token_keys

spring.security.oauth2.client.provider.my-oauth-provider.user-name-attribute=name

By default, Spring Security’s OAuth2LoginAuthenticationFilter will only process URLs matching /login/oauth2/code/*. If you want to customize the redirect-uri-template to use a different pattern, you will need to provide configuration to process that custom pattern. For example, you can add your ownWebSecurityConfigurerAdapter that looks like this:

public class OAuth2LoginSecurityConfig extends WebSecurityConfigurerAdapter {

	@Override

	protected void configure(HttpSecurity http) throws Exception {

		http

			.authorizeRequests()

				.anyRequest().authenticated()

				.and()

			.oauth2Login()

				.redirectionEndpoint()

					.baseUri("/custom-callback");

	}

}

For common OAuth2 and OpenID providers such as Google, Github, Facebook, and Okta, we provide a set of provider defaults (google, github, facebook, and okta respectively).

If you do not need to customize these providers, you can set the provider attribute to the one for which you need to infer defaults. Also if the ID of your client matches the default supported provider, Spring Boot infers that as well.

In other words, the two configurations in the following example use the Google provider:

spring.security.oauth2.client.registration.my-client.client-id=abcd

spring.security.oauth2.client.registration.my-client.client-secret=password

spring.security.oauth2.client.registration.my-client.provider=google

spring.security.oauth2.client.registration.google.client-id=abcd

spring.security.oauth2.client.registration.google.client-secret=password

• The management endpoints are secure even if the application endpoints are insecure.
• Security events are transformed into AuditEvent instances and published to the AuditEventRepository.
• The default user has the ACTUATOR role as well as the USER role.

It is often convenient to develop applications using an in-memory embedded database. Obviously, in-memory databases do not provide persistent storage. You need to populate your database when your application starts and be prepared to throw away data when your application ends.

	The ‘How-to’ section includes a section on how to initialize a database.

Spring Boot can auto-configure embedded H2, HSQL, and Derby databases. You need not provide any connection URLs. You need only include a build dependency to the embedded database that you want to use.

	If you are using this feature in your tests, you may notice that the same database is reused by your whole test suite regardless of the number of application contexts that you use. If you want to make sure that each context has a separate embedded database, you should set spring.datasource.generate-unique-name to true.

For example, typical POM dependencies would be as follows:

<dependency>

	<groupId>org.springframework.boot</groupId>

	<artifactId>spring-boot-starter-data-jpa</artifactId>

</dependency>

<dependency>

	<groupId>org.hsqldb</groupId>

	<artifactId>hsqldb</artifactId>

	<scope>runtime</scope>

</dependency>

	You need a dependency on spring-jdbc for an embedded database to be auto-configured. In this example, it is pulled in transitively viaspring-boot-starter-data-jpa.

If, for whatever reason, you do configure the connection URL for an embedded database, take care to ensure that the database’s automatic shutdown is disabled. If you use H2, you should use DB_CLOSE_ON_EXIT=FALSE to do so. If you use HSQLDB, you should ensure that shutdown=true is not used. Disabling the database’s automatic shutdown lets Spring Boot control when the database is closed, thereby ensuring that it happens once access to the database is no longer needed.

Production database connections can also be auto-configured by using a pooling DataSource. Spring Boot uses the following algorithm for choosing a specific implementation:

If you use the spring-boot-starter-jdbc or spring-boot-starter-data-jpa ‘starters’, you automatically get a dependency to HikariCP.

	You can bypass that algorithm completely and specify the connection pool to use by setting the spring.datasource.type property. This is especially important if you are running your application in a Tomcat container, as tomcat-jdbc is provided by default.

	Additional connection pools can always be configured manually. If you define your own DataSource bean, auto-configuration does not occur.

DataSource configuration is controlled by external configuration properties in spring.datasource.*. For example, you might declare the following section inapplication.properties:

spring.datasource.url=jdbc:mysql://localhost/test

spring.datasource.username=dbuser

spring.datasource.password=dbpass

spring.datasource.driver-class-name=com.mysql.jdbc.Driver

	You should at least specify the URL by setting the spring.datasource.url property. Otherwise, Spring Boot tries to auto-configure an embedded database.

	You often do not need to specify the driver-class-name, since Spring Boot can deduce it for most databases from the url.

	For a pooling DataSource to be created, we need to be able to verify that a valid Driver class is available, so we check for that before doing anything. In other words, if you set spring.datasource.driver-class-name=com.mysql.jdbc.Driver then that class has to be loadable.

See DataSourceProperties for more of the supported options. These are the standard options that work regardless of the actual implementation. It is also possible to fine-tune implementation-specific settings using their respective prefix (spring.datasource.hikari.*, spring.datasource.tomcat.*, and spring.datasource.dbcp2.*). Refer to the documentation of the connection pool implementation you are using for more details.

For instance, if you use the Tomcat connection pool, you could customize many additional settings:

# Number of ms to wait before throwing an exception if no connection is available.

spring.datasource.tomcat.max-wait=10000

# Maximum number of active connections that can be allocated from this pool at the same time.

spring.datasource.tomcat.max-active=50

# Validate the connection before borrowing it from the pool.

spring.datasource.tomcat.test-on-borrow=true

If you deploy your Spring Boot application to an Application Server, you might want to configure and manage your DataSource using your Application Server’s built-in features and access it by using JNDI.

The spring.datasource.jndi-name property can be used as an alternative to the spring.datasource.url, spring.datasource.username, and spring.datasource.password properties to access the DataSource from a specific JNDI location. For example, the following section in application.propertiesshows how you can access a JBoss AS defined DataSource:

spring.datasource.jndi-name=java:jboss/datasources/customers

• Hibernate — One of the most popular JPA implementations.
• Spring Data JPA — Makes it easy to implement JPA-based repositories.
• Spring ORMs — Core ORM support from the Spring Framework.

Traditionally, JPA ‘Entity’ classes are specified in a persistence.xml file. With Spring Boot, this file is not necessary and ‘Entity Scanning’ is used instead. By default, all packages below your main configuration class (the one annotated with @EnableAutoConfiguration or @SpringBootApplication) are searched.

Any classes annotated with @Entity, @Embeddable or @MappedSuperclass are considered. A typical entity class resembles the following example:

package com.example.myapp.domain;

import java.io.Serializable;

import javax.persistence.*;

@Entity

public class City implements Serializable {

	@Id
@GeneratedValue

	private Long id;

	@Column(nullable = false)

	private String name;

	@Column(nullable = false)

	private String state;

	// ... additional members, often include @OneToMany mappings

	protected City() {

		// no-args constructor required by JPA spec

		// this one is protected since it shouldn't be used directly

	}

	public City(String name, String state) {

		this.name = name;

		this.country = country;

	}

	public String getName() {

		return this.name;

	}

	public String getState() {

		return this.state;

	}

	// ... etc

}

	You can customize entity scanning locations by using the @EntityScan annotation. See the “Section 78.4, “Separate @Entity Definitions from Spring Configuration”” how-to.

Spring Data JPA repositories are interfaces that you can define to access data. JPA queries are created automatically from your method names. For example, a CityRepository interface might declare a findAllByState(String state) method to find all the cities in a given state.

For more complex queries, you can annotate your method with Spring Data’s Query annotation.

Spring Data repositories usually extend from the Repository or CrudRepository interfaces. If you use auto-configuration, repositories are searched from the package containing your main configuration class (the one annotated with @EnableAutoConfiguration or @SpringBootApplication) down.

The following example shows a typical Spring Data repository interface definition:

package com.example.myapp.domain;

import org.springframework.data.domain.*;

import org.springframework.data.repository.*;

public interface CityRepository extends Repository<City, Long> {

	Page<City> findAll(Pageable pageable);

	City findByNameAndCountryAllIgnoringCase(String name, String country);

}

	We have barely scratched the surface of Spring Data JPA. For complete details, see the Spring Data JPA reference documentation.

By default, JPA databases are automatically created only if you use an embedded database (H2, HSQL, or Derby). You can explicitly configure JPA settings by usingspring.jpa.* properties. For example, to create and drop tables you can add the following line to your application.properties:

spring.jpa.hibernate.ddl-auto=create-drop

	Hibernate’s own internal property name for this (if you happen to remember it better) is hibernate.hbm2ddl.auto. You can set it, along with other Hibernate native properties, by using spring.jpa.properties.* (the prefix is stripped before adding them to the entity manager). The following line shows an example of setting JPA properties for Hibernate:

spring.jpa.properties.hibernate.globally_quoted_identifiers=true

The line in the preceding example passes a value of true for the hibernate.globally_quoted_identifiers property to the Hibernate entity manager.

By default, the DDL execution (or validation) is deferred until the ApplicationContext has started. There is also a spring.jpa.generate-ddl flag, but it is not used if Hibernate auto-configuration is active, because the ddl-auto settings are more fine-grained.

If you are running a web application, Spring Boot by default registers OpenEntityManagerInViewInterceptor to apply the "Open EntityManager in View" pattern, to allow for lazy loading in web views. If you do not want this behavior, you should set spring.jpa.open-in-view to false in your application.properties.

• You are developing a web application.
• com.h2database:h2 is on the classpath.
• You are using Spring Boot’s developer tools.

By default, the console is available at /h2-console. You can customize the console’s path by using the spring.h2.console.path property.

In order to use jOOQ type-safe queries, you need to generate Java classes from your database schema. You can follow the instructions in the jOOQ user manual. If you use the jooq-codegen-maven plugin and you also use the spring-boot-starter-parent “parent POM”, you can safely omit the plugin’s <version> tag. You can also use Spring Boot-defined version variables (such as h2.version) to declare the plugin’s database dependency. The following listing shows an example:

<plugin>

	<groupId>org.jooq</groupId>

	<artifactId>jooq-codegen-maven</artifactId>

	<executions>

		...

	</executions>

	<dependencies>

		<dependency>

			<groupId>com.h2database</groupId>

			<artifactId>h2</artifactId>

			<version>${h2.version}</version>

		</dependency>

	</dependencies>

	<configuration>

		<jdbc>

			<driver>org.h2.Driver</driver>

			<url>jdbc:h2:~/yourdatabase</url>

		</jdbc>

		<generator>

			...

		</generator>

	</configuration>

</plugin>

The fluent API offered by jOOQ is initiated through the org.jooq.DSLContext interface. Spring Boot auto-configures a DSLContext as a Spring Bean and connects it to your application DataSource. To use the DSLContext, you can @Autowire it, as shown in the following example:

@Component

public class JooqExample implements CommandLineRunner {

	private final DSLContext create;

	@Autowired

	public JooqExample(DSLContext dslContext) {

		this.create = dslContext;

	}

}

	The jOOQ manual tends to use a variable named create to hold the DSLContext.

You can then use the DSLContext to construct your queries, as shown in the following example:

public List<GregorianCalendar> authorsBornAfter1980() {

	return this.create.selectFrom(AUTHOR)

		.where(AUTHOR.DATE_OF_BIRTH.greaterThan(new GregorianCalendar(1980, 0, 1)))

		.fetch(AUTHOR.DATE_OF_BIRTH);

}

Unless the spring.jooq.sql-dialect property has been configured, Spring Boot determines the SQL dialect to use for your datasource. If Spring Boot could not detect the dialect, it uses DEFAULT.

	Spring Boot can only auto-configure dialects supported by the open source version of jOOQ.

More advanced customizations can be achieved by defining your own @Bean definitions, which will be used when the jOOQ Configuration is created. You can define beans for the following jOOQ Types:

You can also create your own org.jooq.Configuration @Bean if you want to take complete control of the jOOQ configuration.

You can inject an auto-configured RedisConnectionFactory, StringRedisTemplate, or vanilla RedisTemplate instance as you would any other Spring Bean. By default, the instance tries to connect to a Redis server at localhost:6379. The following listing shows an example of such a bean:

@Component

public class MyBean {

	private StringRedisTemplate template;

	@Autowired

	public MyBean(StringRedisTemplate template) {

		this.template = template;

	}

	// ...

}

	You can also register an arbitrary number of beans that implement LettuceClientConfigurationBuilderCustomizer for more advanced customizations. If you use Jedis, JedisClientConfigurationBuilderCustomizer is also available.

If you add your own @Bean of any of the auto-configured types, it replaces the default (except in the case of RedisTemplate, when the exclusion is based on the bean name ‘redisTemplate’, not its type). By default, if commons-pool2 is on the classpath, you get a pooled connection factory.

To access Mongo databases, you can inject an auto-configured org.springframework.data.mongodb.MongoDbFactory. By default, the instance tries to connect to a MongoDB server at mongodb://localhost/test The following example shows how to connect to a MongoDB database:

import org.springframework.data.mongodb.MongoDbFactory;

import com.mongodb.DB;

@Component

public class MyBean {

	private final MongoDbFactory mongo;

	@Autowired

	public MyBean(MongoDbFactory mongo) {

		this.mongo = mongo;

	}

	// ...

	public void example() {

		DB db = mongo.getDb();

		// ...

	}

}

You can set the spring.data.mongodb.uri property to change the URL and configure additional settings such as the replica set, as shown in the following example:

spring.data.mongodb.uri=mongodb://user:secret@mongo1.example.com:12345,mongo2.example.com:23456/test

Alternatively, as long as you use Mongo 2.x, you can specify a host/port. For example, you might declare the following settings in your application.properties:

spring.data.mongodb.host=mongoserver

spring.data.mongodb.port=27017

	If you use the Mongo 3.0 Java driver, spring.data.mongodb.host and spring.data.mongodb.port are not supported. In such cases, spring.data.mongodb.uri should be used to provide all of the configuration.

	If spring.data.mongodb.port is not specified, the default of 27017 is used. You could delete this line from the example shown earlier.

	If you do not use Spring Data Mongo, you can inject com.mongodb.Mongo beans instead of using MongoDbFactory. You can also declare your own MongoDbFactory or Mongo bean if you want to take complete control of establishing the MongoDB connection.

Spring Data Mongo provides a MongoTemplate class that is very similar in its design to Spring’s JdbcTemplate. As with JdbcTemplate, Spring Boot auto-configures a bean for you to inject the template, as follows:

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

import org.springframework.data.mongodb.core.MongoTemplate;

import org.springframework.stereotype.Component;

@Component

public class MyBean {

	private final MongoTemplate mongoTemplate;

	@Autowired

	public MyBean(MongoTemplate mongoTemplate) {

		this.mongoTemplate = mongoTemplate;

	}

	// ...

}

See the MongoOperations Javadoc for complete details.

Spring Data includes repository support for MongoDB. As with the JPA repositories discussed earlier, the basic principle is that queries are constructed automatically based on method names.

In fact, both Spring Data JPA and Spring Data MongoDB share the same common infrastructure. You could take the JPA example from earlier and, assuming that Cityis now a Mongo data class rather than a JPA @Entity, it works in the same way, as shown in the following example:

package com.example.myapp.domain;

import org.springframework.data.domain.*;

import org.springframework.data.repository.*;

public interface CityRepository extends Repository<City, Long> {

	Page<City> findAll(Pageable pageable);

	City findByNameAndCountryAllIgnoringCase(String name, String country);

}

	You can customize document scanning locations using the @EntityScan annotation.

	For complete details of Spring Data MongoDB, including its rich object mapping technologies, refer to the reference documentation.

Spring Boot offers auto-configuration for Embedded Mongo. To use it in your Spring Boot application, add a dependency onde.flapdoodle.embed:de.flapdoodle.embed.mongo.

The port that Mongo listens on can be configured by setting the spring.data.mongodb.port property. To use a randomly allocated free port, use a value of 0. The MongoClient created by MongoAutoConfiguration is automatically configured to use the randomly allocated port.

	If you do not configure a custom port, the embedded support uses a random port (rather than 27017) by default.

If you have SLF4J on the classpath, the output produced by Mongo is automatically routed to a logger named org.springframework.boot.autoconfigure.mongo.embedded.EmbeddedMongo.

You can declare your own IMongodConfig and IRuntimeConfig beans to take control of the Mongo instance’s configuration and logging routing.

You can inject an auto-configured Neo4jSession, Session, or Neo4jOperations instance as you would any other Spring Bean. By default, the instance tries to connect to a Neo4j server at localhost:7474. The following example shows how to inject a Neo4j bean:

@Component

public class MyBean {

	private final Neo4jTemplate neo4jTemplate;

	@Autowired

	public MyBean(Neo4jTemplate neo4jTemplate) {

		this.neo4jTemplate = neo4jTemplate;

	}

	// ...

}

You can take full control of the configuration by adding a org.neo4j.ogm.config.Configuration @Bean of your own. Also, adding a @Bean of typeNeo4jOperations disables the auto-configuration.

You can configure the user and credentials to use by setting the spring.data.neo4j.* properties, as shown in the following example:

spring.data.neo4j.uri=http://my-server:7474

spring.data.neo4j.username=neo4j

spring.data.neo4j.password=secret

If you add org.neo4j:neo4j-ogm-embedded-driver to the dependencies of your application, Spring Boot automatically configures an in-process embedded instance of Neo4j that does not persist any data when your application shuts down. You can explicitly disable that mode by setting spring.data.neo4j.embedded.enabled=false. You can also enable persistence for the embedded mode by providing a path to a database file, as shown in the following example:

	spring.data.neo4j.uri=file://var/tmp/graph.db

	The Neo4j OGM embedded driver does not provide the Neo4j kernel. Users are expected to provide this dependency manually. See the documentation for more details.

By default, if you are running a web application, the session is bound to the thread for the entire processing of the request (that is, it uses the "Open Session in View" pattern). If you do not want this behavior, add the following line to your application.properties file:

spring.data.neo4j.open-in-view=false

Spring Data includes repository support for Neo4j.

In fact, both Spring Data JPA and Spring Data Neo4j share the same common infrastructure. You could take the JPA example from earlier and, assuming that City is now a Neo4j OGM @NodeEntity rather than a JPA @Entity, it works in the same way.

	You can customize entity scanning locations by using the @EntityScan annotation.

To enable repository support (and optionally support for @Transactional), add the following two annotations to your Spring configuration:

@EnableNeo4jRepositories(basePackages = "com.example.myapp.repository")

@EnableTransactionManagement

The following examples shows an interface definition for a Neo4j repository:

package com.example.myapp.domain;

import org.springframework.data.domain.*;

import org.springframework.data.repository.*;

public interface CityRepository extends GraphRepository<City> {

	Page<City> findAll(Pageable pageable);

	City findByNameAndCountry(String name, String country);

}

	For complete details of Spring Data Neo4j, including its rich object mapping technologies, refer to the reference documentation.

You can inject an auto-configured SolrClient instance as you would any other Spring bean. By default, the instance tries to connect to a server atlocalhost:8983/solr. The following example shows how to inject a Solr bean:

@Component

public class MyBean {

	private SolrClient solr;

	@Autowired

	public MyBean(SolrClient solr) {

		this.solr = solr;

	}

	// ...

}

If you add your own @Bean of type SolrClient, it replaces the default.

Spring Data includes repository support for Apache Solr. As with the JPA repositories discussed earlier, the basic principle is that queries are constructed for you automatically based on method names.

In fact, both Spring Data JPA and Spring Data Solr share the same common infrastructure. So you could take the JPA example from earlier and, assuming that City is now a @SolrDocument class rather than a JPA @Entity, it works in the same way.

	For complete details of Spring Data Solr, refer to the reference documentation.

If you have Jest on the classpath, you can inject an auto-configured JestClient targeting localhost:9200 by default. You can further tune how the client is configured, as shown in the following example:

spring.elasticsearch.jest.uris=http://search.example.com:9200

spring.elasticsearch.jest.read-timeout=10000

spring.elasticsearch.jest.username=user

spring.elasticsearch.jest.password=secret

You can also register an arbitrary number of beans that implement HttpClientConfigBuilderCustomizer for more advanced customizations. The following example tunes additional HTTP settings:

static class HttpSettingsCustomizer implements HttpClientConfigBuilderCustomizer {

	@Override

	public void customize(HttpClientConfig.Builder builder) {

		builder.maxTotalConnection(100).defaultMaxTotalConnectionPerRoute(5);

	}

}

To take full control over the registration, define a JestClient bean.

To connect to Elasticsearch, you must provide the address of one or more cluster nodes. The address can be specified by setting the spring.data.elasticsearch.cluster-nodes property to a comma-separated ‘host:port’ list. With this configuration in place, an ElasticsearchTemplate or TransportClient can be injected like any other Spring bean, as shown in the following example:

spring.data.elasticsearch.cluster-nodes=localhost:9300

@Component

public class MyBean {

	private final ElasticsearchTemplate template;

	public MyBean(ElasticsearchTemplate template) {

		this.template = template;

	}

	// ...

}

If you add your own ElasticsearchTemplate or TransportClient @Bean, it replaces the default.

Spring Data includes repository support for Elasticsearch. As with the JPA repositories discussed earlier, the basic principle is that queries are constructed for you automatically based on method names.

In fact, both Spring Data JPA and Spring Data Elasticsearch share the same common infrastructure. You could take the JPA example from earlier and, assuming that City is now an Elasticsearch @Document class rather than a JPA @Entity, it works in the same way.

	For complete details of Spring Data Elasticsearch, refer to the reference documentation.

You can inject an auto-configured CassandraTemplate or a Cassandra Session instance as you would with any other Spring Bean. The spring.data.cassandra.*properties can be used to customize the connection. Generally, you provide keyspace-name and contact-points properties, as shown in the following example: