1.3.0.M2
Copyright © 2013-2015
Table of Contents
This section provides a brief overview of Spring Boot reference documentation. Think of it as map for the rest of the document. You can read this reference guide in a linear fashion, or you can skip sections if something doesn’t interest you.
The Spring Boot reference guide is available as html, pdf and epub documents. The latest copy is available at docs.spring.io/spring-boot/docs/current/reference.
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.
Having trouble with Spring Boot, We’d like to help!
spring-boot
.Note | |
---|---|
All of Spring Boot is open source, including the documentation! If you find problems with the docs; or if you just want to improve them, please get involved. |
If you’re just getting started with Spring Boot, or 'Spring' in general, this is the place to start!
Ready to actually start using Spring Boot? We’ve got you covered.
Need more details about Spring Boot’s core features? This is for you!
When you’re ready to push your Spring Boot application to production, we’ve got some tricks that you might like!
Lastly, we have a few topics for the more advanced user.
If you’re just getting started with Spring Boot, or 'Spring' in general, this is the section for you! Here we answer the basic “what?”, “how?” and “why?” questions. You’ll find a gentle introduction to Spring Boot along with installation instructions. We’ll then build our first Spring Boot application, discussing some core principles as we go.
Spring Boot makes it easy to create stand-alone, production-grade Spring based Applications that you can “just run”. We take an opinionated view of the Spring platform and third-party libraries so you can get started with minimum fuss. Most Spring Boot applications need very little Spring configuration.
You can use Spring Boot to create Java applications that can be started using java -jar
or more traditional war deployments. We also provide a command line tool that runs
“spring scripts”.
Our primary goals are:
By default, Spring Boot 1.3.0.M2 requires Java 7 and Spring Framework 4.1.5 or above. You can use Spring Boot with Java 6 with some additional configuration. See Section 76.9, “How to use Java 6” for more details. Explicit build support is provided for Maven (3.2+) and Gradle (1.12+).
Tip | |
---|---|
Although you can use Spring Boot with Java 6 or 7, we generally recommend Java 8 if at all possible. |
The following embedded servlet containers are supported out of the box:
Name | Servlet Version | Java Version |
---|---|---|
Tomcat 8 | 3.1 | Java 7+ |
Tomcat 7 | 3.0 | Java 6+ |
Jetty 9 | 3.1 | Java 7+ |
Jetty 8 | 3.0 | Java 6+ |
Undertow 1.1 | 3.1 | Java 7+ |
You can also deploy Spring Boot applications to any Servlet 3.0+ compatible container.
Spring Boot can be used with “classic” Java development tools or installed as a command line tool. Regardless, you will need Java SDK v1.6 or higher. You should check your current Java installation before you begin:
$ java -version
If you are new to Java development, or if you just want to experiment with Spring Boot you might want to try the Spring Boot CLI first, otherwise, read on for “classic” installation instructions.
Tip | |
---|---|
Although Spring Boot is compatible with Java 1.6, if possible, you should consider using the latest version of Java. |
You can use Spring Boot in the same way as any standard Java library. Simply include the
appropriate spring-boot-*.jar
files on your classpath. Spring Boot does not require
any special tools integration, so you can use any IDE or text editor; and there is
nothing special about a Spring Boot application, so you can run and debug as you would
any other Java program.
Although you could just copy Spring Boot jars, we generally recommend that you use a build tool that supports dependency management (such as Maven or Gradle).
Spring Boot is compatible with Apache Maven 3.2 or above. If you don’t already have Maven installed you can follow the instructions at maven.apache.org.
Tip | |
---|---|
On many operating systems Maven can be installed via a package manager. If you’re an
OSX Homebrew user try |
Spring Boot dependencies use the org.springframework.boot
groupId
. Typically your
Maven POM file will inherit from the spring-boot-starter-parent
project and declare
dependencies to one or more “Starter
POMs”. Spring Boot also provides an optional
Maven plugin to create
executable jars.
Here is 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>1.3.0.M2</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>
Tip | |
---|---|
The |
Spring Boot is compatible with Gradle 1.12 or above. If you don’t already have Gradle installed you can follow the instructions at www.gradle.org/.
Spring Boot dependencies can be declared using the org.springframework.boot
group
.
Typically your project will declare dependencies to one or more
“Starter POMs”. Spring Boot
provides a useful Gradle plugin
that can be used to simplify dependency declarations and to create executable jars.
Here is 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:1.3.0.M2") } } apply plugin: 'java' apply plugin: 'spring-boot' 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") }
The Spring Boot CLI is a command line tool that can be used if you want to quickly prototype with Spring. It allows you to run Groovy scripts, which means that you have a familiar Java-like syntax, without so much boilerplate code.
You don’t need to use the CLI to work with Spring Boot but it’s definitely the quickest way to get a Spring application off the ground.
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, or alternatively you
can use java -jar
with the .jar
file (the script helps you to be sure that the
classpath is set correctly).
GVM (the Groovy Environment Manager) can be used for managing multiple versions of
various Groovy and Java binary packages, including Groovy itself and the Spring Boot CLI.
Get gvm
from gvmtool.net and install Spring Boot with
$ gvm install springboot $ spring --version Spring Boot v1.3.0.M2
If you are developing features for the CLI and want easy access to the version you just built, follow these extra instructions.
$ gvm install springboot dev /path/to/spring-boot/spring-boot-cli/target/spring-boot-cli-1.3.0.M2-bin/spring-1.3.0.M2/ $ gvm use springboot dev $ spring --version Spring CLI v1.3.0.M2
This will install a local instance of spring
called the dev
instance inside your gvm
repository. It points at your target build location, so every time you rebuild Spring
Boot, spring
will be up-to-date.
You can see it by doing this:
$ gvm ls springboot ================================================================================ Available Springboot Versions ================================================================================ > + dev * 1.3.0.M2 ================================================================================ + - local version * - installed > - currently in use ================================================================================
If you are on a Mac and using Homebrew, all you need to do to install the Spring Boot CLI is:
$ brew tap pivotal/tap $ brew install springboot
Homebrew will install spring
to /usr/local/bin
.
Note | |
---|---|
If you don’t see the formula, your installation of brew might be out-of-date.
Just execute |
If you are on a Mac and using MacPorts, all you need to do to install the Spring Boot CLI is:
$ sudo port install spring-boot-cli
Spring Boot CLI ships with scripts that provide command completion for
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. To run the script
manually, e.g. if you have installed using GVM
$ . ~/.gvm/springboot/current/shell-completion/bash/spring $ spring <HIT TAB HERE> grab help jar run test version
Note | |
---|---|
If you install Spring Boot CLI using Homebrew or MacPorts, the command-line completion scripts are automatically registered with your shell. |
Here’s a really simple web application that you can use to test your installation. Create
a file called app.groovy
:
@RestController class ThisWillActuallyRun { @RequestMapping("/") String home() { "Hello World!" } }
Then simply run it from a shell:
$ spring run app.groovy
Note | |
---|---|
It will take some time when you first run the application as dependencies are downloaded. Subsequent runs will be much quicker. |
Open localhost:8080 in your favorite web browser and you should see the following output:
Hello World!
If you are upgrading from an earlier release of Spring Boot check the “release notes” hosted on the project wiki. You’ll find upgrade instructions along with a list of “new and noteworthy” features for each release.
To upgrade an existing CLI installation use the appropriate package manager command
(for example brew upgrade
) or, if you manually installed the CLI, follow the
standard instructions remembering to
update your PATH
environment variable to remove any older references.
Let’s develop a simple “Hello World!” web application in Java that highlights some of Spring Boot’s key features. We’ll use Maven to build this project since most IDEs support it.
Tip | |
---|---|
The spring.io web site contains many “Getting Started” guides that use Spring Boot. If you’re looking to solve a specific problem; check there first. |
Before we begin, open a terminal to check that you have valid versions of Java and Maven installed.
$ java -version java version "1.7.0_51" Java(TM) SE Runtime Environment (build 1.7.0_51-b13) Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
$ mvn -v Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T13:58:10-07:00) Maven home: /Users/user/tools/apache-maven-3.1.1 Java version: 1.7.0_51, vendor: Oracle Corporation
Note | |
---|---|
This sample needs to be created in its own folder. Subsequent instructions assume that you have created a suitable folder and that it is your “current directory”. |
We need to start by creating a Maven pom.xml
file. The pom.xml
is the recipe that
will be used to build your project. Open your favorite text editor and add the following:
<?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> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>1.3.0.M2</version> </parent> <!-- Additional lines to be added here... --> <!-- (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>
This should give you a working build, you can test it out by running mvn package
(you
can ignore the “jar will be empty - no content was marked for inclusion!” warning for
now).
Note | |
---|---|
At this point you could import the project into an IDE (most modern Java IDE’s include built-in support for Maven). For simplicity, we will continue to use a plain text editor for this example. |
Spring Boot provides a number of “Starter POMs” that make easy to add jars to your
classpath. Our sample application has already used spring-boot-starter-parent
in the
parent
section of the POM. The spring-boot-starter-parent
is a special starter
that provides useful Maven defaults. It also provides a dependency-management
section
so that you can omit version
tags for “blessed” dependencies.
Other “Starter POMs” simply provide dependencies that you are likely to need when
developing a specific type of application. Since we are developing a web application, we
will add a spring-boot-starter-web
dependency — but before that, let’s look at what we
currently have.
$ mvn dependency:tree [INFO] com.example:myproject:jar:0.0.1-SNAPSHOT
The mvn dependency:tree
command prints a tree representation of your project dependencies.
You can see that spring-boot-starter-parent
provides no
dependencies by itself. Let’s edit our pom.xml
and add the spring-boot-starter-web
dependency
just below the parent
section:
<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> </dependencies>
If you run mvn dependency:tree
again, you will see that there are now a number of
additional dependencies, including the Tomcat web server and Spring Boot itself.
To finish our application we need to create a single Java file. Maven will compile sources
from src/main/java
by default so you need to create that folder structure, then add a
file named src/main/java/Example.java
:
import org.springframework.boot.*; import org.springframework.boot.autoconfigure.*; import org.springframework.stereotype.*; import org.springframework.web.bind.annotation.*; @RestController @EnableAutoConfiguration public class Example { @RequestMapping("/") String home() { return "Hello World!"; } public static void main(String[] args) throws Exception { SpringApplication.run(Example.class, args); } }
Although there isn’t much code here, quite a lot is going on. Let’s step through the important parts.
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 will consider it when handling incoming web requests.
The @RequestMapping
annotation provides “routing” information. It is telling 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.
Tip | |
---|---|
The |
The second class-level annotation is @EnableAutoConfiguration
. This annotation tells
Spring Boot to “guess” how you will 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 will assume that you are developing a web application
and setup 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
will
bootstrap our application, starting Spring which will in turn start 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.
At this point our application should work. Since we have used the
spring-boot-starter-parent
POM we have a useful run
goal that we can use to start
the application. Type mvn spring-boot:run
from the root project directory to start the
application:
$ mvn spring-boot:run . ____ _ __ _ _ /\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \ ( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \ \\/ ___)| |_)| | | | | || (_| | ) ) ) ) ' |____| .__|_| |_|_| |_\__, | / / / / =========|_|==============|___/=/_/_/_/ :: Spring Boot :: (v1.3.0.M2) ....... . . . ....... . . . (log output here) ....... . . . ........ Started Example in 2.222 seconds (JVM running for 6.514)
If you open a web browser to localhost:8080 you should see the following output:
Hello World!
To gracefully exit the application hit ctrl-c
.
Let’s finish our example by creating a completely self-contained executable jar file that we could run in production. Executable jars (sometimes called “fat jars”) are archives containing your compiled classes along with all of the jar dependencies that your code needs to run.
To create an executable jar we need to add the spring-boot-maven-plugin
to our
pom.xml
. Insert the following lines just below the dependencies
section:
<build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> </plugins> </build>
Note | |
---|---|
The |
Save your pom.xml
and run mvn package
from the command line:
$ mvn package [INFO] Scanning for projects... [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building myproject 0.0.1-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] .... .. [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ myproject --- [INFO] Building jar: /Users/developer/example/spring-boot-example/target/myproject-0.0.1-SNAPSHOT.jar [INFO] [INFO] --- spring-boot-maven-plugin:1.3.0.M2:repackage (default) @ myproject --- [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------
If you look in the target
directory you should see myproject-0.0.1-SNAPSHOT.jar
. The
file should be around 10 Mb in size. If you want to peek inside, you can use jar tvf
:
$ jar tvf target/myproject-0.0.1-SNAPSHOT.jar
You should also see a much smaller file named myproject-0.0.1-SNAPSHOT.jar.original
in the target
directory. This is the original jar file that Maven created before it was
repackaged by Spring Boot.
To run that application, use the java -jar
command:
$ java -jar target/myproject-0.0.1-SNAPSHOT.jar . ____ _ __ _ _ /\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \ ( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \ \\/ ___)| |_)| | | | | || (_| | ) ) ) ) ' |____| .__|_| |_|_| |_\__, | / / / / =========|_|==============|___/=/_/_/_/ :: Spring Boot :: (v1.3.0.M2) ....... . . . ....... . . . (log output here) ....... . . . ........ Started Example in 2.536 seconds (JVM running for 2.864)
As before, to gracefully exit the application hit ctrl-c
.
Hopefully this section has provided you with some of the Spring Boot basics, and got you on your way to writing your own applications. If you’re a task-oriented type of developer you might want to jump over to spring.io and check out some of the getting started guides that solve specific “How do I do that with Spring” problems; we also have Spring Boot-specific How-to reference documentation.
Otherwise, the next logical step is to read Part III, “Using Spring Boot”. If you’re really impatient, you could also jump ahead and read about Spring Boot features.
This section goes into more detail about how you should use Spring Boot. It covers topics such as build systems, auto-configuration and how to run your applications. We also cover some Spring Boot best practices. Although there is nothing particularly special about Spring Boot (it is just another library that you can consume), there are a few recommendations that, when followed, will make your development process just a little easier.
If you’re just starting out with Spring Boot, you should probably read the Getting Started guide before diving into this section.
It is strongly recommended that you choose a build system that supports dependency management, and one that can consume artifacts published to the “Maven Central” repository. We would recommend that you choose Maven or Gradle. It is possible to get Spring Boot to work with other build systems (Ant for example), but they will not be particularly well supported.
Maven users can inherit from the spring-boot-starter-parent
project to obtain sensible
defaults. The parent project provides the following features:
<version>
tags for common
dependencies, inherited from the spring-boot-dependencies
POM.application.properties
and application.yml
On the last point: since the default config files accept
Spring style placeholders (${…}
) the Maven filtering is changed to
use @..@
placeholders (you can override that with a Maven property
resource.delimiter
).
To configure your project to inherit from the spring-boot-starter-parent
simply set
the parent
:
<!-- Inherit defaults from Spring Boot --> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>1.3.0.M2</version> </parent>
Note | |
---|---|
You should only need to specify the Spring Boot version number on this dependency. If you import additional starters, you can safely omit the version number. |
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 just prefer to explicitly
declare all your Maven configuration.
If you don’t 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 a scope=import
dependency:
<dependencyManagement> <dependencies> <dependency> <!-- Import dependency management from Spring Boot --> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-dependencies</artifactId> <version>1.3.0.M2</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement>
The spring-boot-starter-parent
chooses fairly conservative Java compatibility. If you
want to follow our recommendation and use a later Java version you can add a
java.version
property:
<properties> <java.version>1.8</java.version> </properties>
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:
<build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> </plugins> </build>
Note | |
---|---|
If you use the Spring Boot starter parent pom, you only need to add the plugin, there is no need for to configure it unless you want to change the settings defined in the parent. |
Gradle users can directly import “starter POMs” in their dependencies
section. Unlike
Maven, there is no “super parent” to import to share some configuration.
apply plugin: 'java' repositories { maven { url "http://repo.spring.io/snapshot" } maven { url "http://repo.spring.io/milestone" } } dependencies { compile("org.springframework.boot:spring-boot-starter-web:1.3.0.M2") }
The spring-boot-gradle-plugin
is also available and provides tasks to create executable
jars and run projects from source. It also provides
dependency management that, among
other capabilities, allows you to omit the version number for any dependencies that are
managed by Spring Boot:
buildscript { repositories { maven { url "http://repo.spring.io/snapshot" } maven { url "http://repo.spring.io/milestone" } } dependencies { classpath("org.springframework.boot:spring-boot-gradle-plugin:1.3.0.M2") } } apply plugin: 'java' apply plugin: 'spring-boot' repositories { 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") }
It is possible to build a Spring Boot project using Apache Ant+Ivy. The
spring-boot-antlib
“AntLib” module is also available to help Ant create executable
jars.
To declare dependencies a typical ivy.xml
file will look something like this:
<ivy-module version="2.0"> <info organisation="org.springframework.boot" module="spring-boot-sample-ant" /> <configurations> <conf name="compile" description="everything needed to compile this module" /> <conf name="runtime" extends="compile" description="everything needed to run this module" /> </configurations> <dependencies> <dependency org="org.springframework.boot" name="spring-boot-starter" rev="${spring-boot.version}" conf="compile" /> </dependencies> </ivy-module>
A typical build.xml
will look like this:
<project xmlns:ivy="antlib:org.apache.ivy.ant" xmlns:spring-boot="antlib:org.springframework.boot.ant" name="myapp" default="build"> <property name="spring-boot.version" value="1.3.0.BUILD-SNAPSHOT" /> <target name="resolve" description="--> retrieve dependencies with ivy"> <ivy:retrieve pattern="lib/[conf]/[artifact]-[type]-[revision].[ext]" /> </target> <target name="classpaths" depends="resolve"> <path id="compile.classpath"> <fileset dir="lib/compile" includes="*.jar" /> </path> </target> <target name="init" depends="classpaths"> <mkdir dir="build/classes" /> </target> <target name="compile" depends="init" description="compile"> <javac srcdir="src/main/java" destdir="build/classes" classpathref="compile.classpath" /> </target> <target name="build" depends="compile"> <spring-boot:exejar destfile="build/myapp.jar" classes="build/classes"> <spring-boot:lib> <fileset dir="lib/runtime" /> </spring-boot:lib> </spring-boot:exejar> </target> </project>
Tip | |
---|---|
See the Section 76.8, “Build an executable archive from Ant without using spring-boot-antlib” “How-to” if
you don’t want to use the |
Starter POMs are a set of convenient dependency descriptors that you can include in your
application. You get a one-stop-shop for all the Spring and related technology that you
need, without having to hunt through sample code and copy paste loads of dependency
descriptors. For example, if you want to get started using Spring and JPA for database
access, just include the spring-boot-starter-data-jpa
dependency in your project, and
you are good to go.
The starters contain a lot of the dependencies that you need to get a project up and running quickly and with a consistent, supported set of managed transitive dependencies.
The following application starters are provided by Spring Boot under the
org.springframework.boot
group:
Table 13.1. Spring Boot application starters
Name | Description |
---|---|
| The core Spring Boot starter, including auto-configuration support, logging and YAML. |
| Production ready features to help you monitor and manage your application. |
| Support for the “Advanced Message Queuing Protocol” via |
| Support for aspect-oriented programming including |
| Support for “Java Message Service API” via Apache Artemis. |
| Support for “Spring Batch” including HSQLDB database. |
| Support for Spring’s Cache abstraction. |
| Support for “Spring Cloud Connectors” which simplifies connecting to services in cloud platforms like Cloud Foundry and Heroku. |
| Support for the Elasticsearch search and analytics engine including
|
| Support for the GemFire distributed data store including |
| Support for the “Java Persistence API” including |
| Support for the MongoDB NoSQL Database, including |
| Support for exposing Spring Data repositories over REST via |
| Support for the Apache Solr search platform, including |
| Support for the FreeMarker templating engine. |
| Support for the Groovy templating engine. |
| Support for HATEOAS-based RESTful services via |
| Support for “Java Message Service API” via HornetQ. |
| Support for common |
| Support for JDBC databases. |
| Support for the Jersey RESTful Web Services framework. |
| Support for JTA distributed transactions via Atomikos. |
| Support for JTA distributed transactions via Bitronix. |
| Support for |
| Support for |
| Support for the Mustache templating engine. |
| Support for the REDIS key-value data store, including |
| Support for |
| Support for |
| Support for |
| Support for |
| Support for common test dependencies, including JUnit, Hamcrest and Mockito along with
the |
| Support for the Thymeleaf templating engine, including integration with Spring. |
| Support for the Velocity templating engine. |
| Support for full-stack web development, including Tomcat and |
| Support for WebSocket development. |
| Support for Spring Web Services. |
In addition to the application starters, the following starters can be used to add production ready features.
Table 13.2. Spring Boot production ready starters
Name | Description |
---|---|
| Adds production ready features such as metrics and monitoring. |
| Adds remote |
Finally, Spring Boot includes some starters that can be used if you want to exclude or swap specific technical facets.
Table 13.3. Spring Boot technical starters
Name | Description |
---|---|
| Imports the Jetty HTTP engine (to be used as an alternative to Tomcat). |
| Support the Log4J logging framework. |
| Import Spring Boot’s default logging framework (Logback). |
| Import Spring Boot’s default HTTP engine (Tomcat). |
| Imports the Undertow HTTP engine (to be used as an alternative to Tomcat). |
Tip | |
---|---|
For a list of additional community contributed starter POMs, see the
README file in the
|
Spring Boot does not require any specific code layout to work, however, there are some best practices that help.
When a class doesn’t include a package
declaration it is considered to be in the
“default package”. The use of the “default package” is generally discouraged, and
should be avoided. It can cause particular problems for Spring Boot applications that
use @ComponentScan
, @EntityScan
or @SpringBootApplication
annotations, since every
class from every jar, will be read.
Tip | |
---|---|
We recommend that you follow Java’s recommended package naming conventions
and use a reversed domain name (for example, |
We generally recommend that you locate your main application class in a root package
above other classes. The @EnableAutoConfiguration
annotation is often placed on your
main class, and it implicitly defines a base “search package” for certain items. For
example, if you are writing a JPA application, the package of the
@EnableAutoConfiguration
annotated class will be used to search for @Entity
items.
Using a root package also allows the @ComponentScan
annotation to be used without
needing to specify a basePackage
attribute. You can also use the
@SpringBootApplication
annotation if your main class is in the root package.
Here is a typical layout:
com +- example +- myproject +- Application.java | +- domain | +- Customer.java | +- CustomerRepository.java | +- service | +- CustomerService.java | +- web +- CustomerController.java
The Application.java
file would declare the main
method, along with the basic
@Configuration
.
package com.example.myproject; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.EnableAutoConfiguration; import org.springframework.context.annotation.ComponentScan; import org.springframework.context.annotation.Configuration; @Configuration @EnableAutoConfiguration @ComponentScan public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); } }
Spring Boot favors Java-based configuration. Although it is possible to call
SpringApplication.run()
with an XML source, we generally recommend that your primary
source is a @Configuration
class. Usually the class that defines the main
method
is also a good candidate as the primary @Configuration
.
Tip | |
---|---|
Many Spring configuration examples have been published on the Internet that use XML
configuration. Always try to use the equivalent Java-base configuration if possible.
Searching for |
You don’t need to put all your @Configuration
into a single class. The @Import
annotation can be used to import additional configuration classes. Alternatively, you
can use @ComponentScan
to automatically pickup all Spring components, including
@Configuration
classes.
Spring Boot auto-configuration attempts to automatically configure your Spring
application based on the jar dependencies that you have added. For example, If
HSQLDB
is on your classpath, and you have not manually configured any database
connection beans, then we will auto-configure an in-memory database.
You need to opt-in to auto-configuration by adding the @EnableAutoConfiguration
or
@SpringBootApplication
annotations to one of your @Configuration
classes.
Tip | |
---|---|
You should only ever add one |
Auto-configuration is noninvasive, at any point you can start to define your own
configuration to replace specific parts of the auto-configuration. For example, if
you add your own DataSource
bean, the default embedded database support will back away.
If you need to find out what auto-configuration is currently being applied, and why,
starting your application with the --debug
switch. This will log an auto-configuration
report to the console.
If you find that specific auto-configure classes are being applied that you don’t want,
you can use the exclude attribute of @EnableAutoConfiguration
to disable them.
import org.springframework.boot.autoconfigure.*; import org.springframework.boot.autoconfigure.jdbc.*; import org.springframework.context.annotation.*; @Configuration @EnableAutoConfiguration(exclude={DataSourceAutoConfiguration.class}) public class MyConfiguration { }
You are free to use any of the standard Spring Framework techniques to define your beans
and their injected dependencies. For simplicity, we often find that using @ComponentScan
to find your beans, in combination with @Autowired
constructor injection works well.
If you structure your code as suggested above (locating your application class in a root
package), you can add @ComponentScan
without any arguments. All of your application
components (@Component
, @Service
, @Repository
, @Controller
etc.) will be
automatically registered as Spring Beans.
Here is an example @Service
Bean that uses constructor injection to obtain a
required RiskAssessor
bean.
package com.example.service; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.stereotype.Service; @Service public class DatabaseAccountService implements AccountService { private final RiskAssessor riskAssessor; @Autowired public DatabaseAccountService(RiskAssessor riskAssessor) { this.riskAssessor = riskAssessor; } // ... }
Tip | |
---|---|
Notice how using constructor injection allows the |
Many Spring Boot developers always have their main class annotated with @Configuration
,
@EnableAutoConfiguration
and @ComponentScan
. Since these annotations are so frequently
used together (especially if you follow the best practices
above), Spring Boot provides a convenient @SpringBootApplication
alternative.
The @SpringBootApplication
annotation is equivalent to using @Configuration
,
@EnableAutoConfiguration
and @ComponentScan
with their default attributes:
package com.example.myproject; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; @SpringBootApplication // same as @Configuration @EnableAutoConfiguration @ComponentScan public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); } }
One of the biggest advantages of packaging your application as jar and using an embedded HTTP server is that you can run your application as you would any other. Debugging Spring Boot applications is also easy; you don’t need any special IDE plugins or extensions.
Note | |
---|---|
This section only covers jar based packaging, If you choose to package your application as a war file you should refer to your server and IDE documentation. |
You can run a Spring Boot application from your IDE as a simple Java application, however,
first you will need to import your project. Import steps will vary depending on your IDE
and build system. Most IDEs can import Maven projects directly, for example Eclipse users
can select Import…
→ Existing Maven Projects
from the File
menu.
If you can’t directly import your project into your IDE, you may be able to generate IDE metadata using a build plugin. Maven includes plugins for Eclipse and IDEA; Gradle offers plugins for various IDEs.
Tip | |
---|---|
If you accidentally run a web application twice you will see a “Port already in
use” error. STS users can use the |
If you use the Spring Boot Maven or Gradle plugins to create an executable jar you can
run your application using java -jar
. For example:
$ java -jar target/myproject-0.0.1-SNAPSHOT.jar
It is also possible to run a packaged application with remote debugging support enabled. This allows you to attach a debugger to your packaged application:
$ java -Xdebug -Xrunjdwp:server=y,transport=dt_socket,address=8000,suspend=n \ -jar target/myproject-0.0.1-SNAPSHOT.jar
The Spring Boot Maven plugin includes a run
goal which can be used to quickly compile
and run your application. Applications run in an exploded form, and you can edit
resources for instant “hot” reload.
$ mvn spring-boot:run
You might also want to use the useful operating system environment variable:
$ export MAVEN_OPTS=-Xmx1024m -XX:MaxPermSize=128M -Djava.security.egd=file:/dev/./urandom
(The “egd” setting is to speed up Tomcat startup by giving it a faster source of entropy for session keys.)
The Spring Boot Gradle plugin also includes a run
goal which can be used to run
your application in an exploded form. The bootRun
task is added whenever you import
the spring-boot-plugin
$ gradle bootRun
You might also want to use this useful operating system environment variable:
$ export JAVA_OPTS=-Xmx1024m -XX:MaxPermSize=128M -Djava.security.egd=file:/dev/./urandom
Since Spring Boot applications are just plain Java applications, JVM hot-swapping should
work out of the box. JVM hot swapping is somewhat limited with the bytecode that it can
replace, for a more complete solution
JRebel or the
Spring Loaded project can be used. The
spring-boot-devtools
module also includes support for quick application restarts.
See the Chapter 20, Developer tools section below and the Hot swapping “How-to” for details.
Spring Boot includes an additional set of tools that can make the application
development experience a little more pleasant. The spring-boot-devtools
module can be
included in any project to provide additional development-time features. To include
devtools support, simply add the module dependency to your build:
Maven.
<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-devtools</artifactId> </dependency> </dependencies>
Gradle.
dependencies {
compile("org.springframework.boot:spring-boot-devtools")
}
Note | |
---|---|
Developer tools are automatically disabled when running a fully packaged
application. If your application is launched using |
Several of the libraries supported by Spring Boot use caches to improve performance. For example, Thymeleaf will cache templates to save repeatedly parsing XML source files. Whilst caching is very beneficial in production, it can be counter productive during development. If you make a change to a template file in your IDE, you’ll likely want to immediately see the result.
Cache options are usually configured by settings in your application.properties
file.
For example, Thymeleaf offers the spring.thymeleaf.cache
property. Rather than needing
to set these properties manually, the spring-boot-devtools
module will automatically
apply sensible development-time configuration.
Tip | |
---|---|
For a complete list of the properties that are applied see DevToolsPropertyDefaultsPostProcessor. |
Applications that use spring-boot-devtools
will automatically restart whenever files
on the classpath change. This can be a useful feature when working in an IDE as it gives
a very fast feedback loop for code changes. By default, any entry on the classpath that
points to a folder will be monitored for changes.
Tip | |
---|---|
Automatic restart works very well when used with LiveReload. See below for details. |
Certain resources don’t necessarily need to trigger a restart when they are changed. For
example, Thymeleaf templates can just be edited in-place. By default changing resources
in /META-INF/maven
, /META-INF/resources
,/resources
,/static
,/public
or
/templates
will not trigger a restart. 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:
spring.devtools.restart.exclude=static/**,public/**
If you don’t want to use the restart feature you can disable it using the
spring.devtools.restart.enabled
property. In most cases you can set this in your
application.properties
(this will still initialize the restart classloader but it won’t
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 a System
property before calling
SpringApplication.run(…)
. For 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 this you can use a “trigger file”, which is a special file that must be modified when you want to actually trigger a restart check. The trigger file could be updated manually, or via an IDE plugin.
To use a trigger file use the spring.devtools.restart.trigger-file
property.
Tip | |
---|---|
You might want to set |
The spring-boot-devtools
module includes an embedded LiveReload server that can be used
to trigger a browser refresh when a resource is changed. LiveReload browser extensions are
freely available for Chrome, Firefox and Safari from
livereload.com.
If you don’t want to start the LiveReload server when your application runs you can set
the spring.devtools.livereload.enabled
property to false
.
Note | |
---|---|
You can only run one LiveReload server at a time, if you start multiple applications from your IDE only the first will have livereload support. |
You can configure global devtools settings by adding a file named
.spring-boot-devtools.properties
to your $HOME
folder (note that the filename starts
with “.”). Any properties added to this file will apply to all Spring Boot
applications on your machine that use devtools. For example, to configure restart to
always use a trigger file, you would add
the following:
~/.spring-boot-devtools.properties.
spring.devtools.reload.trigger-file=.reloadtrigger
The Spring Boot developer tools are not just limited to local development. You can also
use several features when running applications remotely. Remote support is opt-in, to
enable it you need to set a spring.devtools.remote.secret
property. For example:
spring.devtools.remote.secret=mysecret
Warning | |
---|---|
Enabling |
Remote devtools support is provided in two parts; there is a server side endpoint that
accepts connections, and a client application that you run in your IDE. The server
component is automatically enabled when the spring.devtools.remote.secret
property
is set. The client component must be launched manually.
The remote client application is designed to be run from within you IDE. You need to run
org.springframework.boot.devtools.RemoteSpringApplication
using the same classpath as
the remote project that you’re connecting to. The non-option argument passed to the
application should be the remote URL that you are connecting to.
For example, if you are using Eclipse or STS, and you have a project named my-app
that
you’ve deployed to Cloud Foundry, you would do the following:
Run Configurations…
from the Run
menu.Java Application
“launch configuration”.my-app
project.org.springframework.boot.devtools.RemoteSpringApplication
as the main class.https://myapp.cfapps.io
to the Program arguments
(or whatever your remote
URL is).A running remote client will look like this:
. ____ _ __ _ _ /\\ / ___'_ __ _ _(_)_ __ __ _ ___ _ \ \ \ \ ( ( )\___ | '_ | '_| | '_ \/ _` | | _ \___ _ __ ___| |_ ___ \ \ \ \ \\/ ___)| |_)| | | | | || (_| []::::::[] / -_) ' \/ _ \ _/ -_) ) ) ) ) ' |____| .__|_| |_|_| |_\__, | |_|_\___|_|_|_\___/\__\___|/ / / / =========|_|==============|___/===================================/_/_/_/ :: Spring Boot Remote :: 1.3.0.M2 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)
Note | |
---|---|
Because the remote client is using the same classpath as the real application it
can directly read application properties. This is how the |
Tip | |
---|---|
It’s always advisable to use |
The remote client will monitor your application classpath for changes in the same way as the local restart. Any updated resource will be pushed to the remote application and (if required) trigger a restart. This can be quite helpful if you are iterating on a feature that uses a cloud service that you don’t have locally. Generally remote updates and restarts are much quicker than a full rebuild and deploy cycle.
Note | |
---|---|
Files are only monitored when the remote client is running. If you change a file before starting the remote client, it won’t be pushed to the remote server. |
Java remote debugging is useful when diagnosing issues on a remote application. Unfortunately, it’s not always possible to enable remote debugging when your application is deployed outside of your data center. Remote debugging can also be tricky to setup if you are using a container based technology such as Docker.
To help work around these limitations, devtools supports tunneling of remote debug traffic
over HTTP. The remote client provides a local server on port 8000
that you can attach
a remote debugger to. Once a connection is established, debug traffic is sent over HTTP
to the remote application. You can use the spring.devtools.remote.debug.local-port
property if you want to use a different port.
You’ll need to ensure that your remote application is started with remote debugging
enabled. Often this can be achieved by configuring JAVA_OPTS
. For example, with
Cloud Foundry you can add the following to your manifest.yml
:
--- env: JAVA_OPTS: "-Xdebug -Xrunjdwp:server=y,transport=dt_socket,suspend=n"
Tip | |
---|---|
Notice that you don’t need to pass an |
Note | |
---|---|
Debugging a remote service over the Internet can be slow and you might need to
increase timeouts in your IDE. For example, in Eclipse you can select |
Executable jars can be used for production deployment. As they are self-contained, they are also ideally suited for cloud-based deployment.
For additional “production ready” features, such as health, auditing and metric REST
or JMX end-points; consider adding spring-boot-actuator
. See
Part V, “Spring Boot Actuator: Production-ready features” for details.
You should now have good understanding of how you can use Spring Boot along with some best practices that you should follow. You can now go on to learn about specific Spring Boot features in depth, or you could skip ahead and read about the “production ready” aspects of Spring Boot.
This section dives into the details of Spring Boot. Here you can learn about the key features that you will want to use and customize. If you haven’t already, you might want to read the Part II, “Getting started” and Part III, “Using Spring Boot” sections so that you have a good grounding of the basics.
The SpringApplication
class provides a convenient way to bootstrap a Spring application
that will be started from a main()
method. In many situations you can just delegate to
the static SpringApplication.run
method:
public static void main(String[] args) { SpringApplication.run(MySpringConfiguration.class, args); }
When your application starts you should see something similar to the following:
. ____ _ __ _ _ /\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \ ( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \ \\/ ___)| |_)| | | | | || (_| | ) ) ) ) ' |____| .__|_| |_|_| |_\__, | / / / / =========|_|==============|___/=/_/_/_/ :: Spring Boot :: v1.3.0.M2 2013-07-31 00:08:16.117 INFO 56603 --- [ main] o.s.b.s.app.SampleApplication : Starting SampleApplication v0.1.0 on mycomputer with PID 56603 (/apps/myapp.jar started by pwebb) 2013-07-31 00:08:16.166 INFO 56603 --- [ main] ationConfigEmbeddedWebApplicationContext : Refreshing org.springframework.boot.context.embedded.AnnotationConfigEmbeddedWebApplicationContext@6e5a8246: startup date [Wed Jul 31 00:08:16 PDT 2013]; root of context hierarchy 2014-03-04 13:09:54.912 INFO 41370 --- [ main] .t.TomcatEmbeddedServletContainerFactory : Server initialized with port: 8080 2014-03-04 13:09:56.501 INFO 41370 --- [ main] o.s.b.s.app.SampleApplication : Started SampleApplication in 2.992 seconds (JVM running for 3.658)
By default INFO
logging messages will be shown, including some relevant startup details
such as the user that launched the application.
The banner that is printed on start up can be changed by adding a banner.txt
file
to your classpath, or by setting banner.location
to the location of such a file.
If the file has an unusual encoding you can set banner.charset
(default is UTF-8
).
You can use the following variables inside your banner.txt
file:
Table 23.1. Banner variables
Variable | Description |
---|---|
| The version number of your application as declared in |
| The version number of your application as declared in |
| The Spring Boot version that you are using. For example |
| The Spring Boot version that you are using formatted for display (surrounded with
brackets and prefixed with |
| Where |
Tip | |
---|---|
The |
If the SpringApplication
defaults aren’t to your taste you can instead create a local
instance and customize it. For example, to turn off the banner you would write:
public static void main(String[] args) { SpringApplication app = new SpringApplication(MySpringConfiguration.class); app.setShowBanner(false); app.run(args); }
Note | |
---|---|
The constructor arguments passed to |
It is also possible to configure the SpringApplication
using an application.properties
file. See Chapter 24, Externalized Configuration for details.
For a complete list of the configuration options, see the
SpringApplication
Javadoc.
If you need to build an ApplicationContext
hierarchy (multiple contexts with a
parent/child relationship), or if you just prefer using a ‘fluent’ builder API, you
can use the SpringApplicationBuilder
.
The SpringApplicationBuilder
allows you to chain together multiple method calls, and
includes parent
and child
methods that allow you to create a hierarchy.
For example:
new SpringApplicationBuilder() .showBanner(false) .sources(Parent.class) .child(Application.class) .run(args);
Note | |
---|---|
There are some restrictions when creating an |
In addition to the usual Spring Framework events, such as
ContextRefreshedEvent
,
a SpringApplication
sends some additional application events. Some events are actually
triggered before the ApplicationContext
is created.
You can register event listeners in a number of ways, the most common being
SpringApplication.addListeners(…)
method.
Application events are sent in the following order, as your application runs:
ApplicationStartedEvent
is sent at the start of a run, but before any
processing except the registration of listeners and initializers.ApplicationEnvironmentPreparedEvent
is sent when the Environment
to be used in
the context is known, but before the context is created.ApplicationPreparedEvent
is sent just before the refresh is started, but after bean
definitions have been loaded.ApplicationReadyEvent
is sent after the refresh and any related callbacks have
been processed to indicate the application is ready to service requests.ApplicationFailedEvent
is sent if there is an exception on startup.Tip | |
---|---|
You often won’t need to use application events, but it can be handy to know that they exist. Internally, Spring Boot uses events to handle a variety of tasks. |
A SpringApplication
will attempt to create the right type of ApplicationContext
on
your behalf. By default, an AnnotationConfigApplicationContext
or
AnnotationConfigEmbeddedWebApplicationContext
will be used, depending on whether you
are developing a web application or not.
The algorithm used to determine a ‘web environment’ is fairly simplistic (based on the
presence of a few classes). You can use setWebEnvironment(boolean webEnvironment)
if
you need to override the default.
It is also possible to take complete control of the ApplicationContext
type that will
be used by calling setApplicationContextClass(…)
.
Tip | |
---|---|
It is often desirable to call |
If you need to access the application arguments that were passed to
SpringApplication.run(…)
you can inject a
org.springframework.boot.ApplicationArguments
bean. The ApplicationArguments
interface
provides access to both the raw String[]
arguments as well as parsed option
and
non-option
arguments:
import org.springframework.boot.* import org.springframework.beans.factory.annotation.* import org.springframework.stereotype.* @Component public class MyBean { @Autowired public MyBean(ApplicationArguments args) { boolean debug = args.containsOption("debug"); List<String> files = args.getNonOptionArgs(); // if run with "--debug logfile.txt" debug=true, files=["logfile.txt"] } }
Tip | |
---|---|
Spring Boot will also register a |
If you need to run some specific code once the SpringApplication
has started, you can
implement the ApplicationRunner
or CommandLineRunner
interfaces. Both interfaces work
in the same way and offer a single run
method which will be called just before
SpringApplication.run(…)
completes.
The CommandLineRunner
interfaces provides access to application arguments as a simple
string array, whereas the ApplicationRunner
uses the ApplicationArguments
interface
discussed above.
import org.springframework.boot.* import org.springframework.stereotype.* @Component public class MyBean implements CommandLineRunner { public void run(String... args) { // Do something... } }
You can additionally implement the org.springframework.core.Ordered
interface or use the
org.springframework.core.annotation.Order
annotation if several CommandLineRunner
or
ApplicationRunner
beans are defined that must be called in a specific order.
Each SpringApplication
will register a shutdown hook with the JVM to ensure that the
ApplicationContext
is closed gracefully on exit. All the standard Spring lifecycle
callbacks (such as the DisposableBean
interface, or the @PreDestroy
annotation) can
be used.
In addition, beans may implement the org.springframework.boot.ExitCodeGenerator
interface if they wish to return a specific exit code when the application ends.
It is possible to enable admin-related features for the application by specifying the
spring.application.admin.enabled
property. This exposes the
SpringApplicationAdminMXBean
on the platform MBeanServer
. You could use this feature to administer your Spring Boot
application remotely. This could also be useful for any service wrapper implementation.
Tip | |
---|---|
If you want to know on which HTTP port the application is running, get the property
with key |
Note | |
---|---|
Take care when enabling this feature as the MBean exposes a method to shutdown the application. |
Spring Boot allows you to externalize your configuration so you can work with the same
application code in different environments. You can use properties files, YAML files,
environment variables and command-line arguments to externalize configuration. Property
values can be injected directly into your beans using the @Value
annotation, accessed
via Spring’s Environment
abstraction or bound to structured objects.
Spring Boot uses a very particular PropertySource
order that is designed to allow
sensible overriding of values, properties are considered in the the following order:
java:comp/env
.System.getProperties()
).RandomValuePropertySource
that only has properties in random.*
.application-{profile}.properties
and YAML variants)application-{profile}.properties
and YAML variants)application.properties
and YAML
variants).application.properties
and YAML
variants).@PropertySource
annotations on your @Configuration
classes.SpringApplication.setDefaultProperties
).To provide a concrete example, suppose you develop a @Component
that uses a
name
property:
import org.springframework.stereotype.* import org.springframework.beans.factory.annotation.* @Component public class MyBean { @Value("${name}") private String name; // ... }
You can bundle an application.properties
inside your jar that provides a sensible
default name
. When running in production, an application.properties
can be provided
outside of your jar that overrides name
; and for one-off testing, you can launch with
a specific command line switch (e.g. java -jar app.jar --name="Spring"
).
The RandomValuePropertySource
is useful for injecting random values (e.g. into secrets
or test cases). It can produce integers, longs or strings, e.g.
my.secret=${random.value} my.number=${random.int} my.bignumber=${random.long} my.number.less.than.ten=${random.int(10)} my.number.in.range=${random.int[1024,65536]}
The random.int*
syntax is OPEN value (,max) CLOSE
where the OPEN,CLOSE
are any
character and value,max
are integers. If max
is provided then value
is the minimum
value and max
is the maximum (exclusive).
By default SpringApplication
will convert any command line option arguments (starting
with ‘--’, e.g. --server.port=9000
) to a property
and add it to the Spring
Environment
. As mentioned above, command line properties always take precedence over
other property sources.
If you don’t want command line properties to be added to the Environment
you can disable
them using SpringApplication.setAddCommandLineProperties(false)
.
SpringApplication
will load properties from application.properties
files in the
following locations and add them to the Spring Environment
:
/config
subdir of the current directory./config
packageThe list is ordered by precedence (locations higher in the list override lower items).
Note | |
---|---|
You can also use YAML ('.yml') files as an alternative to '.properties'. |
If you don’t like application.properties
as the configuration file name you can switch
to another by specifying a spring.config.name
environment property. You can also refer
to an explicit location using the spring.config.location
environment property
(comma-separated list of directory locations, or file paths).
$ java -jar myproject.jar --spring.config.name=myproject
or
$ java -jar myproject.jar --spring.config.location=classpath:/default.properties,classpath:/override.properties
If spring.config.location
contains directories (as opposed to files) they should end
in /
(and will be appended with the names generated from spring.config.name
before
being loaded). The default search path classpath:,classpath:/config,file:,file:config/
is always used, irrespective of the value of spring.config.location
. In that way you
can set up default values for your application in application.properties
(or whatever
other basename you choose with spring.config.name
) and override it at runtime with a
different file, keeping the defaults.
Note | |
---|---|
If you use environment variables rather than system properties, most operating
systems disallow period-separated key names, but you can use underscores instead (e.g.
|
Note | |
---|---|
If you are running in a container then JNDI properties (in |
In addition to application.properties
files, profile-specific properties can also be
defined using the naming convention application-{profile}.properties
. The
Environment
has a set of default profiles (by default [default]
) which are
used if no active profiels are set (i.e. if no profiles are explicitly activated
then properties from application-default.properties
are loaded).
Profile specific properties are loaded from the same locations as standard
application.properties
, with profile-specific files always overriding the non-specific
ones irrespective of whether the profile-specific files are inside or outside your
packaged jar.
The values in application.properties
are filtered through the existing Environment
when they are used so you can refer back to previously defined values (e.g. from System
properties).
app.name=MyApp app.description=${app.name} is a Spring Boot application
Tip | |
---|---|
You can also use this technique to create ‘short’ variants of existing Spring Boot properties. See the Section 66.3, “Use ‘short’ command line arguments” how-to for details. |
YAML is a superset of JSON, and as such is a very convenient format
for specifying hierarchical configuration data. The SpringApplication
class will
automatically support YAML as an alternative to properties whenever you have the
SnakeYAML library on your classpath.
Note | |
---|---|
If you use ‘starter POMs’ SnakeYAML will be automatically provided via
|
Spring Framework provides two convenient classes that can be used to load YAML documents.
The YamlPropertiesFactoryBean
will load YAML as Properties
and the
YamlMapFactoryBean
will load YAML as a Map
.
For example, the following YAML document:
environments: dev: url: http://dev.bar.com name: Developer Setup prod: url: http://foo.bar.com name: My Cool App
Would be transformed into these 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 this YAML:
my: servers: - dev.bar.com - foo.bar.com
Would be transformed into these properties:
my.servers[0]=dev.bar.com my.servers[1]=foo.bar.com
To bind to properties like that 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, e.g. this will bind to the properties above
@ConfigurationProperties(prefix="my") public class Config { private List<String> servers = new ArrayList<String>(); public List<String> getServers() { return this.servers; } }
The YamlPropertySourceLoader
class can be used to expose YAML as a PropertySource
in the Spring Environment
. This allows you to use the familiar @Value
annotation 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. For 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 example above, the server.address
property will be 127.0.0.1
if the
development
profile is active. If the development
and production
profiles are not
enabled, then the value for the property will be 192.168.1.100
.
The default profiles are activated if none are explicitly active when the application
context starts. So in this YAML we set a value for security.user.password
that is
only available in the "default" profile:
server: port: 80000 --- spring: profiles: default security: user: password: weak
whereas in this example, the password is always set because it isn’t attached to any profile, and it would have to be explicitly reset in all other profiles as necessary:
server: port: 80000 security: user: password: weak
Using the @Value("${property}")
annotation to inject configuration properties can
sometimes be cumbersome, especially if you are working with multiple properties or
your data is hierarchical in nature. Spring Boot provides an alternative method
of working with properties that allows strongly typed beans to govern and validate
the configuration of your application. For example:
@Component @ConfigurationProperties(prefix="connection") public class ConnectionSettings { private String username; private InetAddress remoteAddress; // ... getters and setters }
Note | |
---|---|
The getters and setters are advisable, since binding is via standard Java Beans
property descriptors, just like in Spring MVC. They are mandatory for immutable types or
those that are directly coercible from |
When the @EnableConfigurationProperties
annotation is applied to your @Configuration
,
any beans annotated with @ConfigurationProperties
will be automatically configured from
the Environment
properties. This style of configuration works particularly well with the
SpringApplication
external YAML configuration:
# application.yml connection: username: admin remoteAddress: 192.168.1.1 # additional configuration as required
To work with @ConfigurationProperties
beans you can just inject them in the same way
as any other bean.
@Service public class MyService { @Autowired private ConnectionSettings connection; //... @PostConstruct public void openConnection() { Server server = new Server(); this.connection.configure(server); } }
It is also possible to shortcut the registration of @ConfigurationProperties
bean
definitions by simply listing the properties classes directly in the
@EnableConfigurationProperties
annotation:
@Configuration @EnableConfigurationProperties(ConnectionSettings.class) public class MyConfiguration { }
Tip | |
---|---|
Using |
As well as using @ConfigurationProperties
to annotate a class, you can also use it
on @Bean
methods. This 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:
@ConfigurationProperties(prefix = "foo") @Bean public FooComponent fooComponent() { ... }
Any property defined with the foo
prefix will be mapped onto that FooComponent
bean
in a similar manner as the ConnectionSettings
example above.
Spring Boot uses some relaxed rules for binding Environment
properties to
@ConfigurationProperties
beans, so there doesn’t need to be an exact match between
the Environment
property name and the bean property name. Common examples where this
is useful include dashed separated (e.g. context-path
binds to contextPath
), and
capitalized (e.g. PORT
binds to port
) environment properties.
For example, given the following @ConfigurationProperties
class:
@Component @ConfigurationProperties(prefix="person") public class ConnectionSettings { private String firstName; public String getFirstName() { return this.firstName; } public void setFirstName(String firstName) { this.firstName = firstName; } }
The following properties names can all be used:
Table 24.1. relaxed binding
Property | Note |
---|---|
| Standard camel case syntax. |
| Dashed notation, recommended for use in |
| Upper case format. Recommended when using a system environment variables. |
Spring will attempt 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 id conversionService
) or custom
property editors (via a CustomEditorConfigurer
bean).
Spring Boot will attempt to validate external configuration, by default using JSR-303
(if it is on the classpath). You can simply add JSR-303 javax.validation
constraint
annotations to your @ConfigurationProperties
class:
@Component @ConfigurationProperties(prefix="connection") public class ConnectionSettings { @NotNull private InetAddress remoteAddress; // ... getters and setters }
You can also add a custom Spring Validator
by creating a bean definition called
configurationPropertiesValidator
.
Tip | |
---|---|
The |
Spring Profiles provide a way to segregate parts of your application configuration and
make it only available in certain environments. Any @Component
or @Configuration
can
be marked with @Profile
to limit when it is loaded:
@Configuration @Profile("production") public class ProductionConfiguration { // ... }
In the normal Spring way, you can use a spring.profiles.active
Environment
property to specify which profiles are active. You can
specify the property in any of the usual ways, for example you could
include it in your application.properties
:
spring.profiles.active=dev,hsqldb
or specify on the command line using the switch --spring.profiles.active=dev,hsqldb
.
The spring.profiles.active
property follows the same ordering rules as other
properties, the highest PropertySource
will win. This means that you can specify
active profiles in application.properties
then replace them using the command line
switch.
Sometimes it is useful to have profile specific properties that add to the active
profiles rather than replace them. The spring.profiles.include
property can be used
to unconditionally add active profiles. The SpringApplication
entry point also has
a Java API for setting additional profiles (i.e. on top of those activated by the
spring.profiles.active
property): see the setAdditionalProfiles()
method.
For example, when an application with following properties is run using the switch
--spring.profiles.active=prod
the proddb
and prodmq
profiles will also be activated:
--- my.property: fromyamlfile --- spring.profiles: prod spring.profiles.include: proddb,prodmq
Note | |
---|---|
Remember that the |
You can programmatically set active profiles by calling
SpringApplication.setAdditionalProfiles(…)
before your application runs. It is also
possible to activate profiles using Spring’s ConfigurableEnvironment
interface.
Profile specific variants of both application.properties
(or application.yml
) and
files referenced via @ConfigurationProperties
are considered as files are loaded.
See Section 24.4, “Profile-specific properties” for details.
Spring Boot uses Commons Logging for all internal logging, but leaves the underlying log implementation open. Default configurations are provided for Java Util Logging, Log4J, Log4J2 and Logback. In each case loggers are pre-configured to use console output with optional file output also available.
By default, If you use the ‘Starter POMs’, Logback will be used for logging. Appropriate Logback routing is also included to ensure that dependent libraries that use Java Util Logging, Commons Logging, Log4J or SLF4J will all work correctly.
Tip | |
---|---|
There are a lot of logging frameworks available for Java. Don’t worry if the above list seems confusing. Generally you won’t need to change your logging dependencies and the Spring Boot defaults will work just fine. |
The default log output from Spring Boot looks like this:
2014-03-05 10:57:51.112 INFO 45469 --- [ main] org.apache.catalina.core.StandardEngine : Starting Servlet Engine: Apache Tomcat/7.0.52 2014-03-05 10:57:51.253 INFO 45469 --- [ost-startStop-1] o.a.c.c.C.[Tomcat].[localhost].[/] : Initializing Spring embedded WebApplicationContext 2014-03-05 10:57:51.253 INFO 45469 --- [ost-startStop-1] o.s.web.context.ContextLoader : Root WebApplicationContext: initialization completed in 1358 ms 2014-03-05 10:57:51.698 INFO 45469 --- [ost-startStop-1] o.s.b.c.e.ServletRegistrationBean : Mapping servlet: 'dispatcherServlet' to [/] 2014-03-05 10:57:51.702 INFO 45469 --- [ost-startStop-1] o.s.b.c.embedded.FilterRegistrationBean : Mapping filter: 'hiddenHttpMethodFilter' to: [/*]
The following items are output:
ERROR
, WARN
, INFO
, DEBUG
or TRACE
.---
separator to distinguish the start of actual log messages.The default log configuration will echo messages to the console as they are written. By
default ERROR
, WARN
and INFO
level messages are logged. To also log DEBUG
level
messages to the console you can start your application with a --debug
flag.
$ java -jar myapp.jar --debug
Note | |
---|---|
you can also specify |
If your terminal supports ANSI, color output will be used to aid readability. You can set
spring.output.ansi.enabled
to a
supported value to override the auto
detection.
By default, Spring Boot will only log to the console and will not write log files. If you
want to write log files in addition to the console output you need to set a
logging.file
or logging.path
property (for example in your application.properties
).
The following table shows how the logging.*
properties can be used together:
Table 26.1. Logging properties
|
| Example | Description |
(none) | (none) | Console only logging. | |
Specific file | (none) |
| Writes to the specified log file. Names can be an exact location or relative to the current directory. |
(none) | Specific directory |
| Writes |
Log files will rotate when they reach 10 Mb and as with console output, ERROR
, WARN
and INFO
level messages are logged by default.
Note | |
---|---|
The logging system is initialized early in the application lifecycle and as such
logging properties will not be found in property files loaded via |
All the supported logging systems can have the logger levels set in the Spring
Environment
(so for example in application.properties
) using
‘logging.level.*=LEVEL’ where ‘LEVEL’ is one of TRACE, DEBUG, INFO, WARN, ERROR,
FATAL, OFF. Example application.properties
:
logging.level.org.springframework.web=DEBUG logging.level.org.hibernate=ERROR
Note | |
---|---|
By default Spring Boot remaps Thymeleaf |
The various logging systems can be activated by including the appropriate libraries on
the classpath, and further customized by providing a suitable configuration file in the
root of the classpath, or in a location specified by the Spring Environment
property
logging.config
.
Note | |
---|---|
Since logging is initialized before the |
Depending on your logging system, the following files will be loaded:
Logging System | Customization |
---|---|
Logback |
|
Log4j |
|
Log4j2 |
|
JDK (Java Util Logging) |
|
Note | |
---|---|
When possible we recommend that you use the |
Warning | |
---|---|
There are known classloading issues with Java Util Logging that cause problems when running from an ‘executable jar’. We recommend that you avoid it if at all possible. |
To help with the customization some other properties are transferred from the Spring
Environment
to System properties:
Spring Environment | System Property | Comments |
---|---|---|
|
| Used in default log configuration if defined. |
|
| Used in default log configuration if defined. |
|
| The current process ID (discovered if possible and when not already defined as an OS environment variable). |
All the logging systems supported can consult System properties when parsing their
configuration files. See the default configurations in spring-boot.jar
for examples.
Spring Boot includes a number of extensions to Logback which can help with advanced
configuration. You can use these extensions in your logback-spring.xml
configuration
file.
Note | |
---|---|
You cannot use extensions in the standard |
The <springProfile>
tag allows you to 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.
<springProfile name="staging"> <!-- configuration to be enabled when the "staging" profile is active --> </springProfile> <springProfile name="!production"> <!-- configuration to be enabled when the "production" profile is not active --> </springProfile>
The <springProperty>
tag allows you to surface properties from the Spring Environment
for use within Logback. This 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, but rather than specifying a direct value
you specify the source
of the property (from the Environment
). You can use the scope
attribute if you need to store the property somewhere other than in local
scope.
<springProperty scope="context" name="fluentHost" source="myapp.fulentd.host"/> <appender name="FLUENT" class="ch.qos.logback.more.appenders.DataFluentAppender"> <remoteHost>${fluentHost}</remoteHost> ... </appender>
Tip | |
---|---|
The |
Spring Boot is well suited for web application development. You can easily create a
self-contained HTTP server using embedded Tomcat, Jetty, or Undertow. Most web
applications will use the spring-boot-starter-web
module to get up and running quickly.
If you haven’t yet developed a Spring Boot web application you can follow the "Hello World!" example in the Getting started section.
The Spring Web MVC framework (often referred to as simply ‘Spring MVC’) is a rich
‘model view controller’ web framework. Spring MVC lets you create special @Controller
or @RestController
beans to handle incoming HTTP requests. Methods in your controller
are mapped to HTTP using @RequestMapping
annotations.
Here is a typical example @RestController
to serve JSON data:
@RestController @RequestMapping(value="/users") public class MyRestController { @RequestMapping(value="/{user}", method=RequestMethod.GET) public User getUser(@PathVariable Long user) { // ... } @RequestMapping(value="/{user}/customers", method=RequestMethod.GET) List<Customer> getUserCustomers(@PathVariable Long user) { // ... } @RequestMapping(value="/{user}", method=RequestMethod.DELETE) public User deleteUser(@PathVariable Long user) { // ... } }
Spring MVC is part of the core Spring Framework and detailed information is available in the reference documentation. There are also several guides available at spring.io/guides that cover Spring MVC.
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:
ContentNegotiatingViewResolver
and BeanNameViewResolver
beans.Converter
, GenericConverter
, Formatter
beans.HttpMessageConverters
(see below).MessageCodesResolver
(see below).index.html
support.Favicon
support.If you want to take complete control of Spring MVC, you can add your own @Configuration
annotated with @EnableWebMvc
. If you want to keep Spring Boot MVC features, and
you just want to add additional MVC configuration (interceptors,
formatters, view controllers etc.) you can add your own @Bean
of type
WebMvcConfigurerAdapter
, but without @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 (using the Jackson library) or XML (using the Jackson
XML extension if available, else using JAXB). Strings are encoded using UTF-8
by
default.
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 will be added to the list of
converters. You can also override default converters that way.
Spring MVC has a strategy for generating error codes for rendering error messages
from binding errors: MessageCodesResolver
. Spring Boot will create one for you if
you set the spring.mvc.message-codes-resolver.format
property PREFIX_ERROR_CODE
or
POSTFIX_ERROR_CODE
(see the enumeration in DefaultMessageCodesResolver.Format
).
By default Spring Boot will serve 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 you
can modify that behavior by adding your own WebMvcConfigurerAdapter
and 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 will always be able to handle requests
through the DispatcherServlet
.
You can customize the static resource locations using spring.resources.staticLocations
(replacing the default values with a list of directory locations). If you do this the
default welcome page detection will switch to your custom locations, so if there is an
index.html
in any of your locations on startup, it will be the home page of the
application.
In addition to the ‘standard’ static resource locations above, a special case is made
for Webjars content. Any resources with a path in /webjars/**
will be served from jar files if they are packaged in the Webjars format.
Tip | |
---|---|
Do not use the |
Spring Boot also supports advanced resource handling features provided by Spring MVC, allowing use cases such as cache busting static resources or using version agnostic URLs for Webjars.
For example, the following configuration will configure a cache busting solution
for all static resources, effectively adding a content hash in URLs, such as
<link href="/css/spring-2a2d595e6ed9a0b24f027f2b63b134d6.css"/>
:
spring.resources.chain.strategy.content.enabled=true spring.resources.chain.strategy.content.paths=/**
Note | |
---|---|
Links to resources are rewritten at runtime in template, thanks to a
|
When loading resources dynamically with, for example, a JavaScript module loader, renaming files is not an option. That’s why other strategies are also supported and can be combined. A "fixed" strategy will add a static version string in the URL, without changing the file name:
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/"
will use a fixed
versioning strategy "/v12/js/lib/mymodule.js"
while other resources will still use
the content one <link href="/css/spring-2a2d595e6ed9a0b24f027f2b63b134d6.css"/>
.
See ResourceProperties
for more of the supported options.
Tip | |
---|---|
This feature has been thoroughly described in a dedicated blog post and in Spring Framework’s reference documentation. |
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 Velocity, FreeMarker and JSPs. Many other templating engines also ship their own Spring MVC integrations.
Spring Boot includes auto-configuration support for the following templating engines:
Tip | |
---|---|
JSPs should be avoided if possible, there are several known limitations when using them with embedded servlet containers. |
When you’re using one of these templating engines with the default configuration, your
templates will be picked up automatically from src/main/resources/templates
.
Tip | |
---|---|
IntelliJ IDEA orders the classpath differently depending on how you run your
application. Running your application in the IDE via its main method will result in a
different ordering to when you run your application 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’re affected by 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: |
Spring Boot provides an /error
mapping by default 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 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 view that renders
the same data in HTML format (to customize it just add a View
that resolves to
‘error’). To replace the default behaviour completely you can implement
ErrorController
and register a bean definition of that type, or simply add a bean of
type ErrorAttributes
to use the existing mechanism but replace the contents.
If you want more specific error pages for some conditions, the embedded servlet containers support a uniform Java DSL for customizing the error handling. For example:
@Bean public EmbeddedServletContainerCustomizer containerCustomizer(){ return new MyCustomizer(); } // ... private static class MyCustomizer implements EmbeddedServletContainerCustomizer { @Override public void customize(ConfigurableEmbeddedServletContainer container) { container.addErrorPages(new ErrorPage(HttpStatus.BAD_REQUEST, "/400")); } }
You can also use regular Spring MVC features like
@ExceptionHandler
methods and
@ControllerAdvice
. The ErrorController
will then pick up any unhandled exceptions.
N.B. if you register an ErrorPage
with a path that will end up being handled by a
Filter
(e.g. 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, e.g.
@Bean public FilterRegistrationBean myFilter() { FilterRegistrationBean registration = new FilterRegistrationBean(); registration.setFilter(new MyFilter()); ... registration.setDispatcherTypes(EnumSet.allOf(DispatcherType.class)); return registration; }
(the default FilterRegistrationBean
does not include the ERROR
dispatcher type).
When deployed to a servlet container, a Spring Boot uses its error page filter to forward
a request with an error status to the appropriate error page. The request can only be
forwarded to the correct error page if the response has not already been committed. By
default, WebSphere Application Server 8.0 and later commits the response upon successful
completion of a servlet’s service method. You should disable this behaviour by setting
com.ibm.ws.webcontainer.invokeFlushAfterService
to false
If you’re developing 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 a
LinkDiscoverers
(for client side support) and an ObjectMapper
configured to correctly
marshal responses into the desired representation. The ObjectMapper
will be customized based on the
spring.jackson.*
properties or a Jackson2ObjectMapperBuilder
bean if one exists.
You can take control of Spring HATEOAS’s configuration by using
@EnableHypermediaSupport
. Note that this will disable the ObjectMapper
customization
described above.
If you prefer the JAX-RS programming model for REST endpoints you can use one of the
available implementations instead of Spring MVC. Jersey 1.x and Apache Celtix work quite
well out of the box if you just register their Servlet
or Filter
as a @Bean
in your
application context. Jersey 2.x has some native Spring support so we also provide
auto-configuration support for it in Spring Boot together with a starter.
To get started with Jersey 2.x just include the spring-boot-starter-jersey
as a
dependency and then you need one @Bean
of type ResourceConfig
in which you register
all the endpoints:
@Component public class JerseyConfig extends ResourceConfig { public JerseyConfig() { register(Endpoint.class); } }
All the registered endpoints should be @Components
with HTTP resource annotations
(@GET
etc.), e.g.
@Component @Path("/hello") public class Endpoint { @GET public String message() { return "Hello"; } }
Since the Endpoint
is a Spring @Component
its lifecycle is managed by Spring and you
can @Autowired
dependencies and inject external configuration with @Value
. The Jersey
servlet will be registered and mapped to /*
by default. You can change the mapping
by adding @ApplicationPath
to your ResourceConfig
.
By default Jersey will be set up as a Servlet in a @Bean
of type
ServletRegistrationBean
named jerseyServletRegistration
. You can disable or override
that bean by creating one of your own with the same name. You can also use a Filter
instead of a Servlet by setting spring.jersey.type=filter
(in which case the @Bean
to
replace or override is jerseyFilterRegistration
). The servlet has an @Order
which you
can set with spring.jersey.filter.order
. Both the Servlet and the Filter registrations
can be given init parameters using spring.jersey.init.*
to specify a map of properties.
There is a Jersey sample so
you can see how to set things up. There is also a
Jersey 1.x sample. Note that
in the Jersey 1.x sample that the spring-boot maven plugin has been configured to unpack
some Jersey jars so they can be scanned by the JAX-RS implementation (because the sample
asks for them to be scanned in its Filter
registration). You may need to do the same if
any of your JAX-RS resources are packages as nested jars.
Spring Boot includes support for embedded Tomcat, Jetty, and Undertow servers. Most
developers will simply use the appropriate ‘Starter POM’ to obtain a fully configured
instance. By default the embedded server will listen for HTTP requests on port 8080
.
When using an embedded servlet container you can register Servlets, Filters and all the
listeners from the Servlet spec (e.g. HttpSessionListener
) directly as
Spring beans. This can be particularly convenient if you want to refer to a value from
your application.properties
during configuration.
By default, if the context contains only a single Servlet it will be mapped to /
. In the
case of multiple Servlet beans the bean name will be used as a path prefix. Filters will
map to /*
.
If convention-based mapping is not flexible enough you can use the
ServletRegistrationBean
, FilterRegistrationBean
and ServletListenerRegistrationBean
classes for complete control. You can also register items directly if your bean implements
the ServletContextInitializer
interface.
Under the hood Spring Boot uses a new type of ApplicationContext
for embedded servlet
container support. The EmbeddedWebApplicationContext
is a special type of
WebApplicationContext
that bootstraps itself by searching for a single
EmbeddedServletContainerFactory
bean. Usually a TomcatEmbeddedServletContainerFactory
,
JettyEmbeddedServletContainerFactory
, or UndertowEmbeddedServletContainerFactory
will
have been auto-configured.
Note | |
---|---|
You usually won’t need to be aware of these implementation classes. Most
applications will be auto-configured and the appropriate |
Common servlet container settings can be configured using Spring Environment
properties. Usually you would define the properties in your application.properties
file.
Common server settings include:
server.port
— The listen port for incoming HTTP requests.server.address
— The interface address to bind to.server.sessionTimeout
— A session timeout.See the ServerProperties
class for a complete list.
If you need to configure your embdedded servlet container programmatically you can
register a Spring bean that implements the EmbeddedServletContainerCustomizer
interface.
EmbeddedServletContainerCustomizer
provides access to the
ConfigurableEmbeddedServletContainer
which includes numerous customization setter
methods.
import org.springframework.boot.context.embedded.*; import org.springframework.stereotype.Component; @Component public class CustomizationBean implements EmbeddedServletContainerCustomizer { @Override public void customize(ConfigurableEmbeddedServletContainer container) { container.setPort(9000); } }
If the above customization techniques are too limited, you can register the
TomcatEmbeddedServletContainerFactory
, JettyEmbeddedServletContainerFactory
or
UndertowEmbeddedServletContainerFactory
bean yourself.
@Bean public EmbeddedServletContainerFactory servletContainer() { TomcatEmbeddedServletContainerFactory factory = new TomcatEmbeddedServletContainerFactory(); factory.setPort(9000); factory.setSessionTimeout(10, TimeUnit.MINUTES); factory.addErrorPages(new ErrorPage(HttpStatus.NOT_FOUND, "/notfound.html")); return factory; }
Setters are provided for many configuration options. Several protected method ‘hooks’ are also provided should you need to do something more exotic. See the source code documentation for details.
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 you can see how to set things up.
If Spring Security is on the classpath then web applications will be secure by default
with ‘basic’ authentication on all HTTP endpoints. To add method-level security to a web
application you can also add @EnableGlobalMethodSecurity
with your desired settings.
Additional information can be found in the Spring
Security Reference.
The default AuthenticationManager
has a single user (‘user’ username and random
password, printed at INFO level when the application starts up)
Using default security password: 78fa095d-3f4c-48b1-ad50-e24c31d5cf35
Note | |
---|---|
If you fine tune your logging configuration, ensure that the
|
You can change the password by providing a security.user.password
. This and other useful
properties are externalized via
SecurityProperties
(properties prefix "security").
The default security configuration is implemented in SecurityAutoConfiguration
and in
the classes imported from there (SpringBootWebSecurityConfiguration
for web security
and AuthenticationManagerConfiguration
for authentication configuration which is also
relevant in non-web applications). To switch off the Boot default configuration
completely in a web application you can add a bean with @EnableWebSecurity
. To customize
it you normally use external properties and beans of type WebSecurityConfigurerAdapter
(e.g. to add form-based login). There are several secure applications in the
Spring Boot samples to get you started with common
use cases.
The basic features you get out of the box in a web application are:
AuthenticationManager
bean with in-memory store and a single user (see
SecurityProperties.User
for the properties of the user)./css/**
, /js/**
,
/images/**
and **/favicon.ico
).ApplicationEventPublisher
(successful and
unsuccessful authentication and access denied).All of the above can be switched on and off or modified using external properties
(security.*
). To override the access rules without changing any other autoconfigured
features add a @Bean
of type WebSecurityConfigurerAdapter
with
@Order(SecurityProperties.ACCESS_OVERRIDE_ORDER)
.
If you have spring-security-oauth2
on your classpath you can take advantage of some
auto-configuration to make it easy to set up Authorization or Resource Server.
To create an Authorization Server and grant access tokens you need to use
@EnableAuthorizationServer
and provide security.oauth2.client.client-id
and
security.oauth2.client.client-secret]
properties. The client will be registered for you
in an in-memory repository.
Having done that you will be able to use the client credentials to create an access token, for example:
$ curl client:secret@localhost:8080/oauth/token -d grant_type=password -d username=user -d password=pwd
The basic auth credentials for the /token
endpoint are the client-id
and
client-secret
. The user credentials are the normal Spring Security user details (which
default in Spring Boot to “user” and a random password).
To switch off the auto-configuration and configure the Authorization Server features
yourself just add a @Bean
of type AuthorizationServerConfigurer
.
To use the access token you need a Resource Server (which can be the same as the
Authorization Server). Creating a Resource Server is easy, just add
@EnableResourceServer
and provide some configuration to allow the server to decode
access tokens. If your appplication is also an Authorization Server it already knows how
to decode tokens, so there is nothing else to do. If your app is a standalone service then you
need to give it some more configuration, one of the following options:
security.oauth2.resource.user-info-uri
to use the /me
resource (e.g.
uaa.run.pivotal.io/userinfo
on PWS)security.oauth2.resource.token-info-uri
to use the token decoding endpoint (e.g.
uaa.run.pivotal.io/check_token
on PWS).If you specify both the user-info-uri
and the token-info-uri
then you can set a flag
to say that one is preferred over the other (prefer-token-info=true
is the default).
Alternatively (instead of user-info-uri
or token-info-uri
) if the tokens are JWTs you
can configure a security.oauth2.resource.jwt.key-value
to decode them locally (where the
key is a verification key). The verification key value is either a symmetric secret or
PEM-encoded RSA public key. If you don’t have the key and it’s public you can provide a
URI where it can be downloaded (as a JSON object with a “value” field) with
security.oauth2.resource.jwt.key-uri
. E.g. on PWS:
$ curl https://uaa.run.pivotal.io/token_key {"alg":"SHA256withRSA","value":"-----BEGIN PUBLIC KEY-----\nMIIBI...\n-----END PUBLIC KEY-----\n"}
Warning | |
---|---|
If you use the |
Google, and certain other 3rd party identity providers, are more strict about the token
type name that is sent in the headers to the user info endpoint. The default is “Bearer”
which suits most providers and matches the spec, but if you need to change it you can set
security.oauth2.resource.token-type
.
If you have a user-info-uri
, the resource server features use an OAuth2RestTemplate
internally to fetch user details for authentication. This is provided as a qualified
@Bean
with id userInfoRestTemplate
, but you shouldn’t need to know that to just
use it. The default should be fine for most providers, but occasionally you might need to
add additional interceptors, or change the request authenticator (which is how the token
gets attached to outgoing requests). To add a customization just create a bean of type
UserInfoRestTemplateCustomizer
- it has a single method that will be called after the
bean is created but before it is initialized. The rest template that is being customized
here is only used internally to carry out authentication.
Tip | |
---|---|
To set an RSA key value in YAML use the “pipe” continuation marker to split it over multiple lines (“|”) and remember to indent the key value (it’s a standard YAML language feature). Example: security: oauth2: resource: jwt: keyValue: | -----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC... -----END PUBLIC KEY----- |
To make your webapp into an OAuth2 client you can simply add @EnableOAuth2Client
and
Spring Boot will create an OAuth2RestTemplate
for you to @Autowire
. It uses the
security.oauth2.client.*
as credentials (the same as you might be using in the
Authorization Server), but in addition it will need to know the authorization and token
URIs in the Authorization Server. For example:
application.yml.
security: oauth2: client: clientId: bd1c0a783ccdd1c9b9e4 clientSecret: 1a9030fbca47a5b2c28e92f19050bb77824b5ad1 accessTokenUri: https://github.com/login/oauth/access_token userAuthorizationUri: https://github.com/login/oauth/authorize clientAuthenticationScheme: form
An application with this configuration will redirect to Github for authorization when you
attempt to use the OAuth2RestTemplate
. If you are already signed into Github you won’t
even notice that it has authenticated. These specific credentials will only work if your
application is running on port 8080 (register your own client app in Github or other
provider for more flexibility).
To limit the scope that the client asks for when it obtains an access token you can set
security.oauth2.client.scope
(comma separated or an array in YAML). By default the scope
is empty and it is up to to Authorization Server to decide what the defaults should be,
usually depending on the settings in the client registration that it holds.
Note | |
---|---|
There is also a setting for |
Tip | |
---|---|
In a non-web application you can still |
An OAuth2 Client can be used to fetch user details from the provider (if such features are
available) and then convert them into an Authentication
token for Spring Security.
The Resource Server above support this via the user-info-uri
property This is the basis
for a Single Sign On (SSO) protocol based on OAuth2, and Spring Boot makes it easy to
participate by providing an annotation @EnableOAuth2Sso
. The Github client above can
protect all its resources and authenticate using the Github /user/
endpoint, by adding
that annotation and declaring where to find the endpoint (in addition to the
security.oauth2.client.*
configuration already listed above):
application.yml.
security: oauth2: ... resource: userInfoUri: https://api.github.com/user preferTokenInfo: false
Since all paths are secure by default, there is no “home” page that you can show to
unauthenticated users and invite them to login (by visiting the /login
path, or the
path specified by security.oauth2.sso.login-path
).
To customize the access rules or paths to protect, so you can add a “home” page for
instance, @EnableOAuth2Sso
can be added to a WebSecurityConfigurerAdapter
and the
annotation will cause it to be decorated and enhanced with the necessary pieces to get
the /login
path working. For example, here we simply allow unauthenticated access
to the home page at "/" and keep the default for everything else:
@Configuration public class WebSecurityConfiguration extends WebSecurityConfigurerAdapter { @Override public void init(WebSecurity web) { web.ignore("/"); } @Override protected void configure(HttpSecurity http) throws Exception { http.antMatcher("/**").authorizeRequests().anyRequest().authenticated(); } }
If the Actuator is also in use, you will find:
AuditEvents
and published to the AuditService
.ADMIN
role as well as the USER
role.The Actuator security features can be modified using external properties
(management.security.*
). To override the application access rules
add a @Bean
of type WebSecurityConfigurerAdapter
and use
@Order(SecurityProperties.ACCESS_OVERRIDE_ORDER)
if you don’t want to override
the actuator access rules, or @Order(ManagementServerProperties.ACCESS_OVERRIDE_ORDER)
if you do want to override the actuator access rules.
The Spring Framework provides extensive support for working with SQL databases. From
direct JDBC access using JdbcTemplate
to complete ‘object relational mapping’
technologies such as Hibernate. Spring Data provides an additional level of functionality,
creating Repository
implementations directly from interfaces and using conventions to
generate queries from your method names.
Java’s javax.sql.DataSource
interface provides a standard method of working with
database connections. Traditionally a DataSource uses a URL
along with some
credentials to establish a database connection.
It’s often convenient to develop applications using an in-memory embedded database. Obviously, in-memory databases do not provide persistent storage; you will need to populate your database when your application starts and be prepared to throw away data when your application ends.
Tip | |
---|---|
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 don’t need to provide any connection URLs, simply include a build dependency to the embedded database that you want to use.
For example, typical POM dependencies would be:
<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>
Note | |
---|---|
You need a dependency on |
Production database connections can also be auto-configured using a pooling DataSource
.
Here’s the algorithm for choosing a specific implementation:
DataSource
for its performance and concurrency, so if
that is available we always choose it.If you use the spring-boot-starter-jdbc
or spring-boot-starter-data-jpa
‘starter POMs’ you will automatically get a dependency to tomcat-jdbc
.
Note | |
---|---|
Additional connection pools can always be configured manually. If you define your
own |
DataSource configuration is controlled by external configuration properties in
spring.datasource.*
. For example, you might declare the following section in
application.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
See DataSourceProperties
for more of the supported options. Note also that you can configure any of the
DataSource
implementation specific properties via spring.datasource.*
: refer to the
documentation of the connection pool implementation you are using for more details.
Tip | |
---|---|
You often won’t need to specify the |
Note | |
---|---|
For a pooling |
If you are deploying your Spring Boot application to an Application Server you might want to configure and manage your DataSource using your Application Servers built-in features and access it 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.properties
shows how you can access a JBoss AS defined
DataSource
:
spring.datasource.jndi-name=java:jboss/datasources/customers
Spring’s JdbcTemplate
and NamedParameterJdbcTemplate
classes are auto-configured and
you can @Autowire
them directly into your own beans:
import org.springframework.beans.factory.annotation.Autowired; import org.springframework.jdbc.core.JdbcTemplate; import org.springframework.stereotype.Component; @Component public class MyBean { private final JdbcTemplate jdbcTemplate; @Autowired public MyBean(JdbcTemplate jdbcTemplate) { this.jdbcTemplate = jdbcTemplate; } // ... }
The Java Persistence API is a standard technology that allows you to ‘map’ objects to
relational databases. The spring-boot-starter-data-jpa
POM provides a quick way to get
started. It provides the following key dependencies:
Tip | |
---|---|
We won’t go into too many details of JPA or Spring Data here. You can follow the ‘Accessing Data with JPA’ guide from spring.io and read the Spring Data JPA and Hibernate reference documentation. |
Traditionally, JPA ‘Entity’ classes are specified in a persistence.xml
file. With
Spring Boot this file is not necessary and instead ‘Entity Scanning’ is used. By default
all packages below your main configuration class (the one annotated with
@EnableAutoConfiguration
or @SpringBootApplication
) will be searched.
Any classes annotated with @Entity
, @Embeddable
or @MappedSuperclass
will be
considered. A typical entity class would look something like this:
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 }
Tip | |
---|---|
You can customize entity scanning locations using the |
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 cities in a
given state.
For more complex queries you can annotate your method using Spring Data’s
Query
annotation.
Spring Data repositories usually extend from the
Repository
or
CrudRepository
interfaces.
If you are using auto-configuration, repositories will be searched from the package
containing your main configuration class (the one annotated with
@EnableAutoConfiguration
or @SpringBootApplication
) down.
Here is a typical Spring Data repository:
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); }
Tip | |
---|---|
We have barely scratched the surface of Spring Data JPA. For complete details check their reference documentation. |
By default, JPA databases will be automatically created only if you use an embedded
database (H2, HSQL or Derby). You can explicitly configure JPA settings using
spring.jpa.*
properties. For example, to create and drop tables you can add the
following to your application.properties
.
spring.jpa.hibernate.ddl-auto=create-drop
Note | |
---|---|
Hibernate’s own internal property name for this (if you happen to remember it
better) is |
spring.jpa.properties.hibernate.globally_quoted_identifiers=true
passes hibernate.globally_quoted_identifiers
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 autoconfig is active because the ddl-auto
settings are more fine-grained.
Java Object Oriented Querying (jOOQ) is a popular product from Data Geekery which generates Java code from your database, and lets you build type safe SQL queries through its fluent API. Both the commercial and open source editions can be used with Spring Boot.
In oder 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 are using 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 (e.g. h2.version
) to
declare the plugin’s database dependency. Here’s 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 via the org.jooq.DSLContext
interface.
Spring Boot will auto-configure a DSLContext
as a Spring Bean and connect it to your
application DataSource
. To use the DSLContext
you can just @Autowire
it:
@Component public class JooqExample implements CommandLineRunner { private final DSLContext create; @Autowired public JooqExample(DSLContext dlsContext) { this.create = dlsContext; } }
Tip | |
---|---|
The jOOQ manual tends to use a variable named |
You can then use the DSLContext
to construct your queries:
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); }
You can customize the SQL dialect used by jOOQ by setting spring.jooq.sql-dialect
in
your application.properties
. For example, to specify Postgres you would add:
spring.jooq.sql-dialect=Postgres
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:
ConnectionProvider
TransactionProvider
RecordMapperProvider
RecordListenerProvider
ExecuteListenerProvider
VisitListenerProvider
You can also create your own org.jooq.Configuration
@Bean
if you want to take
complete control of the jOOQ configuration.
Spring Data provides additional projects that help you access a variety of NoSQL technologies including MongoDB, Neo4J, Elasticsearch, Solr, Redis, Gemfire, Couchbase and Cassandra. Spring Boot provides auto-configuration for Redis, MongoDB, Elasticsearch, and Solr; you can make use of the other projects, but you will need to configure them yourself. Refer to the appropriate reference documentation at projects.spring.io/spring-data.
Redis is a cache, message broker and richly-featured key-value store.
Spring Boot offers basic auto-configuration for the
Jedis client library and abstractions on top of it
provided by Spring Data Redis. There
is a spring-boot-starter-redis
‘Starter POM’ for collecting the dependencies in a
convenient way.
You can inject an auto-configured RedisConnectionFactory
, StringRedisTemplate
or
vanilla RedisTemplate
instance as you would any other Spring Bean. By default the
instance will attempt to connect to a Redis server using localhost:6379
:
@Component public class MyBean { private StringRedisTemplate template; @Autowired public MyBean(StringRedisTemplate template) { this.template = template; } // ... }
If you add a @Bean
of your own of any of the auto-configured types it will replace the
default (except in the case of RedisTemplate
the exclusion is based on the bean name
‘redisTemplate’ not its type). If commons-pool2
is on the classpath you will get a
pooled connection factory by default.
MongoDB is an open-source NoSQL document database that uses a
JSON-like schema instead of traditional table-based relational data. Spring Boot offers
several conveniences for working with MongoDB, including the
spring-boot-starter-data-mongodb
‘Starter POM’.
You can inject an auto-configured org.springframework.data.mongodb.MongoDbFactory
to
access Mongo databases. By default the instance will attempt to connect to a MongoDB
server using the URL mongodb://localhost/test
:
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 spring.data.mongodb.uri
property to change the url
, or alternatively
specify a host
/port
. For example, you might declare the following in your
application.properties
:
spring.data.mongodb.host=mongoserver spring.data.mongodb.port=27017
Tip | |
---|---|
If |
Tip | |
---|---|
If you aren’t using Spring Data Mongo you can inject |
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 simply inject:
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 for you automatically based on method names.
In fact, both Spring Data JPA and Spring Data MongoDB share the same common
infrastructure; so you could take the JPA example from earlier and, assuming that City
is now a Mongo data class rather than a JPA @Entity
, it will work in the same way.
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); }
Tip | |
---|---|
For complete details of Spring Data MongoDB, including its rich object mapping technologies, refer to their reference documentation. |
Spring Data Gemfire provides
convenient Spring-friendly tools for accessing the
Pivotal Gemfire data management
platform. There is a spring-boot-starter-data-gemfire
‘Starter POM’ for collecting the
dependencies in a convenient way. There is currently no auto-configuration support for
Gemfire, but you can enable Spring Data Repositories with a
single annotation (@EnableGemfireRepositories
).
Apache Solr is a search engine. Spring Boot offers basic
auto-configuration for the Solr client library and abstractions on top of it provided by
Spring Data Solr. There is
a spring-boot-starter-data-solr
‘Starter POM’ for collecting the dependencies in a
convenient way.
You can inject an auto-configured SolrServer
instance as you would any other Spring
bean. By default the instance will attempt to connect to a server using
localhost:8983/solr
:
@Component public class MyBean { private SolrServer solr; @Autowired public MyBean(SolrServer solr) { this.solr = solr; } // ... }
If you add a @Bean
of your own of type SolrServer
it will replace 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 will work in the same way.
Tip | |
---|---|
For complete details of Spring Data Solr, refer to their reference documentation. |
Elasticsearch is an open source, distributed,
real-time search and analytics engine. Spring Boot offers basic auto-configuration for
the Elasticsearch and abstractions on top of it provided by
Spring Data Elasticsearch.
There is a spring-boot-starter-data-elasticsearch
‘Starter POM’ for collecting the
dependencies in a convenient way.
You can inject an auto-configured ElasticsearchTemplate
or Elasticsearch Client
instance as you would any other Spring Bean. By default the instance will attempt to
connect to a local in-memory server (a NodeClient
in Elasticsearch terms), but you can
switch to a remote server (i.e. a TransportClient
) by setting
spring.data.elasticsearch.cluster-nodes
to a comma-separated ‘host:port’ list.
@Component public class MyBean { private ElasticsearchTemplate template; @Autowired public MyBean(ElasticsearchTemplate template) { this.template = template; } // ... }
If you add a @Bean
of your own of type ElasticsearchTemplate
it will replace 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; so you could take the JPA example from earlier and, assuming that
City
is now an Elasticsearch @Document
class rather than a JPA @Entity
, it will
work in the same way.
Tip | |
---|---|
For complete details of Spring Data Elasticsearch, refer to their reference documentation. |
The Spring Framework provides support for transparently adding caching to an application. At its core, the abstraction applies caching to methods, reducing thus the number of executions based on the information available in the cache. The caching logic is applied transparently, without any interference to the invoker.
Note | |
---|---|
Check the relevant section of the Spring Framework reference for more details. |
In a nutshell, adding caching to an operation of your service is as easy as adding the relevant annotation to its method:
import javax.cache.annotation.CacheResult; import org.springframework.stereotype.Component; @Component public class MathService { @CacheResult public int computePiDecimal(int i) { // ... } }
Note | |
---|---|
You can either use the standard JSR-107 (JCache) annotations or Spring’s own caching annotations transparently. We strongly advise you however to not mix and match them. |
The cache abstraction does not provide an actual store and relies on a abstraction
materialized by the org.springframework.cache.Cache
and
org.springframework.cache.CacheManager
interfaces. Spring Boot auto-configures a
suitable CacheManager
according to the implementation as long as the caching support is
enabled via the @EnableCaching
annotation.
Tip | |
---|---|
Use the |
Spring Boot tries to detect the following providers (in this order):
It is also possible to force the cache provider to use via the spring.cache.type
property.
Generic caching is used if the context defines at least one
org.springframework.cache.Cache
bean, a CacheManager
wrapping them is configured.
EhCache 2.x is used if a file named ehcache.xml
can be found at the root of the
classpath. If EhCache 2.x and such file is present it is used to bootstrap the cache
manager. An alternate configuration file can be provide a well using:
spring.cache.ehcache.config=classpath:config/another-config.xml
Hazelcast is used if a hazelcast.xml
file can be found in the current working
directory, at the root of the classpath or a location specified via the hazelcast.config
system property. Spring Boot detects all of these and also allows for explicit location
using:
spring.cache.hazelcast.config=classpath:config/my-hazelcast.xml
Infinispan has no default configuration file location so it must be specified explicitly (or the default bootstrap is used).
spring.cache.infinispan.config=infinispan.xml
Caches can be created on startup via the spring.cache.cache-names
property. If a custom
ConfigurationBuilder
bean is defined, it is used to customize them.
JCache is bootstrapped via the presence of a javax.cache.spi.CachingProvider
on the
classpath (i.e. a JSR-107 compliant caching library). It might happen than more that one
provider is present, in which case the provider must be explicitly specified. Even if the
JSR-107 standard does not enforce a standardized way to define the location of the
configuration file, Spring Boot does its best to accommodate with implementation details.
# Only necessary if more than one provider is present spring.cache.jcache.provider=com.acme.MyCachingProvider spring.cache.jcache.config=classpath:acme.xml
Note | |
---|---|
Since a cache library may offer both a native implementation and JSR-107 support
it is advised to set the |
There are several ways to customize the underlying javax.cache.cacheManager
:
spring.cache.cache-names
property. If a custom
javax.cache.configuration.Configuration
bean is defined, it is used to customize them.org.springframework.boot.autoconfigure.cache.JCacheManagerCustomizer
beans are
invoked with the reference of the CacheManager
for full customization.Tip | |
---|---|
If a standard |
If Redis is available and configured, the RedisCacheManager
is auto-configured. It is
also possible to create additional caches on startup using the spring.cache.cache-names
property.
If Guava is present, a GuavaCacheManager
is auto-configured. Caches can be created
on startup using the spring.cache.cache-names
property and customized by one of the
following (in this order):
spring.cache.guava.spec
com.google.common.cache.CacheBuilderSpec
bean is definedcom.google.common.cache.CacheBuilder
bean is definedFor instance, the following configuration creates a foo
and bar
caches with a maximum
size of 500 and a time to live of 10 minutes
spring.cache.cache-names=foo,bar spring.cache.guava.spec=maximumSize=500,expireAfterAccess=600s
Besides, if a com.google.common.cache.CacheLoader
bean is defined, it is automatically
associated to the GuavaCacheManager
.
The Spring Framework provides extensive support for integrating with messaging systems:
from simplified use of the JMS API using JmsTemplate
to a complete infrastructure to
receive messages asynchronously. Spring AMQP provides a similar feature set for the
‘Advanced Message Queuing Protocol’ and Spring Boot also provides auto-configuration
options for RabbitTemplate
and RabbitMQ. There is also support for STOMP messaging
natively in Spring WebSocket and Spring Boot has support for that through starters and a
small amount of auto-configuration.
The javax.jms.ConnectionFactory
interface provides a standard method of creating a
javax.jms.Connection
for interacting with a JMS broker. Although Spring needs a
ConnectionFactory
to work with JMS, you generally won’t need to use it directly yourself
and you can instead rely on higher level messaging abstractions (see the
relevant section of the Spring Framework reference
documentation for details). Spring Boot also auto-configures the necessary infrastructure
to send and receive messages.
Spring Boot can also configure a ConnectionFactory
when it detects that ActiveMQ is
available on the classpath. If the broker is present, an embedded broker is started and
configured automatically (as long as no broker URL is specified through configuration).
ActiveMQ configuration is controlled by external configuration properties in
spring.activemq.*
. For example, you might declare the following section in
application.properties
:
spring.activemq.broker-url=tcp://192.168.1.210:9876 spring.activemq.user=admin spring.activemq.password=secret
See
ActiveMQProperties
for more of the supported options.
By default, ActiveMQ creates a destination if it does not exist yet, so destinations are resolved against their provided names.
Apache Artemis was formed in 2015 when HornetQ was donated to the Apache Foundation. All
the features listed in the Section 33.1.3, “HornetQ support” section below can be applied to
Artemis. Simply replace spring.hornetq.*
properties with spring.artemis.*
and use spring-boot-starter-artemis
instead of spring-boot-starter-hornetq
.
Note | |
---|---|
You should not try and use Artemis and HornetQ and the same time. |
Spring Boot can auto-configure a ConnectionFactory
when it detects that HornetQ is
available on the classpath. If the broker is present, an embedded broker is started and
configured automatically (unless the mode property has been explicitly set). The supported
modes are: embedded
(to make explicit that an embedded broker is required and should
lead to an error if the broker is not available in the classpath), and native
to connect
to a broker using the netty
transport protocol. When the latter is configured, Spring
Boot configures a ConnectionFactory
connecting to a broker running on the local machine
with the default settings.
Note | |
---|---|
If you are using |
HornetQ configuration is controlled by external configuration properties in
spring.hornetq.*
. For example, you might declare the following section in
application.properties
:
spring.hornetq.mode=native spring.hornetq.host=192.168.1.210 spring.hornetq.port=9876
When embedding the broker, you can choose if you want to enable persistence, and the list
of destinations that should be made available. These can be specified as a comma-separated
list to create them with the default options; or you can define bean(s) of type
org.hornetq.jms.server.config.JMSQueueConfiguration
or
org.hornetq.jms.server.config.TopicConfiguration
, for advanced queue and topic
configurations respectively.
See
HornetQProperties
for more of the supported options.
No JNDI lookup is involved at all and destinations are resolved against their names, either using the ‘name’ attribute in the HornetQ configuration or the names provided through configuration.
If you are running your application in an Application Server Spring Boot will attempt to
locate a JMS ConnectionFactory
using JNDI. By default the locations java:/JmsXA
and
java:/XAConnectionFactory
will be checked. You can use the
spring.jms.jndi-name
property if you need to specify an alternative location:
spring.jms.jndi-name=java:/MyConnectionFactory
Spring’s JmsTemplate
is auto-configured and you can autowire it directly into your own
beans:
import org.springframework.beans.factory.annotation.Autowired; import org.springframework.jms.core.JmsTemplate; import org.springframework.stereotype.Component; @Component public class MyBean { private final JmsTemplate jmsTemplate; @Autowired public MyBean(JmsTemplate jmsTemplate) { this.jmsTemplate = jmsTemplate; } // ... }
Note | |
---|---|
|
When the JMS infrastructure is present, any bean can be annotated with @JmsListener
to
create a listener endpoint. If no JmsListenerContainerFactory
has been defined, a
default one is configured automatically.
The default factory is transactional by default. If you are running in an infrastructure
where a JtaTransactionManager
is present, it will be associated to the listener container
by default. If not, the sessionTransacted
flag will be enabled. In that latter scenario,
you can associate your local data store transaction to the processing of an incoming message
by adding @Transactional
on your listener method (or a delegate thereof). This will make
sure that the incoming message is acknowledged once the local transaction has completed. This
also includes sending response messages that have been performed on the same JMS session.
The following component creates a listener endpoint on the someQueue
destination:
@Component public class MyBean { @JmsListener(destination = "someQueue") public void processMessage(String content) { // ... } }
Tip | |
---|---|
Check the Javadoc of |
The Advanced Message Queuing Protocol (AMQP) is a platform-neutral, wire-level protocol for message-oriented middleware. The Spring AMQP project applies core Spring concepts to the development of AMQP-based messaging solutions.
RabbitMQ is a lightweight, reliable, scalable and portable message broker based on the
AMQP protocol. Spring uses RabbitMQ
to communicate using the AMQP protocol.
RabbitMQ configuration is controlled by external configuration properties in
spring.rabbitmq.*
. For example, you might declare the following section in
application.properties
:
spring.rabbitmq.host=localhost spring.rabbitmq.port=5672 spring.rabbitmq.username=admin spring.rabbitmq.password=secret
See RabbitProperties
for more of the supported options.
Tip | |
---|---|
Check Understanding AMQP, the protocol used by RabbitMQ for more details. |
Spring’s AmqpTemplate
and AmqpAdmin
are auto-configured and you can autowire them
directly into your own beans:
import org.springframework.amqp.core.AmqpAdmin; import org.springframework.amqp.core.AmqpTemplate; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.stereotype.Component; @Component public class MyBean { private final AmqpAdmin amqpAdmin; private final AmqpTemplate amqpTemplate; @Autowired public MyBean(AmqpAdmin amqpAdmin, AmqpTemplate amqpTemplate) { this.adminTemplate = adminTemplate; this.amqpTemplate = amqpTemplate; } // ... }
Note | |
---|---|
|
Any org.springframework.amqp.core.Queue
that is defined as a bean will be automatically
used to declare a corresponding queue on the RabbitMQ instance if necessary.
When the Rabbit infrastructure is present, any bean can be annotated with
@RabbitListener
to create a listener endpoint. If no RabbitListenerContainerFactory
has been defined, a default one is configured automatically.
The following component creates a listener endpoint on the someQueue
queue:
@Component public class MyBean { @RabbitListener(queues = "someQueue") public void processMessage(String content) { // ... } }
Tip | |
---|---|
Check the Javadoc of |
The Spring Framework provides an easy abstraction for sending email using the
JavaMailSender
interface and Spring Boot provides auto-configuration for it as well as
a starter module.
Tip | |
---|---|
Check the reference documentation for a detailed
explanation of how you can use |
If spring.mail.host
and the relevant libraries (as defined by
spring-boot-starter-mail
) are available, a default JavaMailSender
is created if none
exists. The sender can be further customized by configuration items from the spring.mail
namespace, see the
MailProperties
for more
details.
Spring Boot supports distributed JTA transactions across multiple XA resources using either an Atomikos or Bitronix embedded transaction manager. JTA transactions are also supported when deploying to a suitable Java EE Application Server.
When a JTA environment is detected, Spring’s JtaTransactionManager
will be used to
manage transactions. Auto-configured JMS, DataSource and JPA beans will be upgraded to
support XA transactions. You can use standard Spring idioms such as @Transactional
to
participate in a distributed transaction. If you are within a JTA environment and still
want to use local transactions you can set the spring.jta.enabled
property to false
to
disable the JTA auto-configuration.
Atomikos is a popular open source transaction manager which can be embedded into your
Spring Boot application. You can use the spring-boot-starter-jta-atomikos
Starter POM to
pull in the appropriate Atomikos libraries. Spring Boot will auto-configure Atomikos and
ensure that appropriate depends-on
settings are applied to your Spring beans for correct
startup and shutdown ordering.
By default Atomikos transaction logs will be written to a transaction-logs
directory in
your application home directory (the directory in which your application jar file
resides). You can customize this directory by setting a spring.jta.log-dir
property in
your application.properties
file. Properties starting spring.jta.
can also be used to
customize the Atomikos UserTransactionServiceImp
. See the
AtomikosProperties
Javadoc
for complete details.
Note | |
---|---|
To ensure that multiple transaction managers can safely coordinate the same
resource managers, each Atomikos instance must be configured with a unique ID. By default
this ID is the IP address of the machine on which Atomikos is running. To ensure
uniqueness in production, you should configure the |
Bitronix is another popular open source JTA transaction manager implementation. You can
use the spring-boot-starter-jta-bitronix
starter POM to add the appropriate Birtronix
dependencies to your project. As with Atomikos, Spring Boot will automatically configure
Bitronix and post-process your beans to ensure that startup and shutdown ordering is
correct.
By default Bitronix transaction log files (part1.btm
and part2.btm
) will be written to
a transaction-logs
directory in your application home directory. You can customize this
directory by using the spring.jta.log-dir
property. Properties starting spring.jta.
are also bound to the bitronix.tm.Configuration
bean, allowing for complete
customization. See the
Bitronix documentation
for details.
Note | |
---|---|
To ensure that multiple transaction managers can safely coordinate the same
resource managers, each Bitronix instance must be configured with a unique ID. By default
this ID is the IP address of the machine on which Bitronix is running. To ensure
uniqueness in production, you should configure the |
If you are packaging your Spring Boot application as a war
or ear
file and deploying
it to a Java EE application server, you can use your application servers built-in
transaction manager. Spring Boot will attempt to auto-configure a transaction manager by
looking at common JNDI locations (java:comp/UserTransaction
,
java:comp/TransactionManager
etc). If you are using a transaction service provided by
your application server, you will generally also want to ensure that all resources are
managed by the server and exposed over JNDI. Spring Boot will attempt to auto-configure
JMS by looking for a ConnectionFactory
at the JNDI path java:/JmsXA
or
java:/XAConnectionFactory
and you can use the
spring.datasource.jndi-name
property
to configure your DataSource
.
When using JTA, the primary JMS ConnectionFactory
bean will be XA aware and participate
in distributed transactions. In some situations you might want to process certain JMS
messages using a non-XA ConnectionFactory
. For example, your JMS processing logic might
take longer than the XA timeout.
If you want to use a non-XA ConnectionFactory
you can inject the
nonXaJmsConnectionFactory
bean rather than the @Primary
jmsConnectionFactory
bean.
For consistency the jmsConnectionFactory
bean is also provided using the bean alias
xaJmsConnectionFactory
.
For example:
// Inject the primary (XA aware) ConnectionFactory @Autowired private ConnectionFactory defaultConnectionFactory; // Inject the XA aware ConnectionFactory (uses the alias and injects the same as above) @Autowired @Qualifier("xaJmsConnectionFactory") private ConnectionFactory xaConnectionFactory; // Inject the non-XA aware ConnectionFactory @Autowired @Qualifier("nonXaJmsConnectionFactory") private ConnectionFactory nonXaConnectionFactory;
The XAConnectionFactoryWrapper
and XADataSourceWrapper
interfaces
can be used to support alternative embedded transaction managers. The interfaces are
responsible for wrapping XAConnectionFactory
and XADataSource
beans and exposing them
as regular ConnectionFactory
and DataSource
beans which will transparently enroll in
the distributed transaction. DataSource and JMS auto-configuration will use JTA variants
as long as you have a JtaTransactionManager
bean and appropriate XA wrapper beans
registered within your ApplicationContext
.
The BitronixXAConnectionFactoryWrapper and BitronixXADataSourceWrapper provide good examples of how to write XA wrappers.
Spring Integration provides abstractions over messaging and also other transports such as
HTTP, TCP etc. If Spring Integration is available on your classpath it will be initialized
through the @EnableIntegration
annotation. Message processing statistics will be
published over JMX if 'spring-integration-jmx'
is also on the classpath. See the
IntegrationAutoConfiguration
class for more details.
Spring Session provides support for managing a user’s session information. If you are
writing a web application and Spring Session and Spring Data Redis are both on the
classpath, Spring Boot will auto-configure Spring Session through its
@EnableRedisHttpSession
. Session data will be stored in Redis and the session timeout
can be configured using the server.session-timeout
property.
Java Management Extensions (JMX) provide a standard mechanism to monitor and manage
applications. By default Spring Boot will create an MBeanServer
with bean id
‘mbeanServer’ and expose any of your beans that are annotated with Spring JMX
annotations (@ManagedResource
, @ManagedAttribute
, @ManagedOperation
).
See the
JmxAutoConfiguration
class for more details.
Spring Boot provides a number of useful tools for testing your application. The
spring-boot-starter-test
POM provides Spring Test, JUnit, Hamcrest and Mockito
dependencies. There are also useful test utilities in the core spring-boot
module under
the org.springframework.boot.test
package.
If you use the
spring-boot-starter-test
‘Starter POM’ (in the test
scope
), you will find
the following provided libraries:
assertThat
style JUnit assertions.These are common libraries that we generally find useful when writing tests. You are free to add additional test dependencies of your own if these don’t suit your needs.
One of the major advantages of dependency injection is that it should make your code
easier to unit test. You can simply instantiate objects using the new
operator without
even involving Spring. You can also use mock objects instead of real dependencies.
Often you need to move beyond ‘unit testing’ and start ‘integration testing’ (with
a Spring ApplicationContext
actually involved in the process). It’s useful to be able
to perform integration testing without requiring deployment of your application or
needing to connect to other infrastructure.
The Spring Framework includes a dedicated test module for just such integration testing.
You can declare a dependency directly to org.springframework:spring-test
or use the
spring-boot-starter-test
‘Starter POM’ to pull it in transitively.
If you have not used the spring-test
module before you should start by reading the
relevant section of the Spring Framework reference
documentation.
A Spring Boot application is just a Spring ApplicationContext
so nothing very special
has to be done to test it beyond what you would normally do with a vanilla Spring context.
One thing to watch out for though is that the external properties, logging and other
features of Spring Boot are only installed in the context by default if you use
SpringApplication
to create it.
Spring Boot provides a @SpringApplicationConfiguration
annotation as an alternative
to the standard spring-test
@ContextConfiguration
annotation. If you use
@SpringApplicationConfiguration
to configure the ApplicationContext
used in your
tests, it will be created via SpringApplication
and you will get the additional Spring
Boot features.
For example:
@RunWith(SpringJUnit4ClassRunner.class) @SpringApplicationConfiguration(classes = SampleDataJpaApplication.class) public class CityRepositoryIntegrationTests { @Autowired CityRepository repository; // ... }
Tip | |
---|---|
The context loader guesses whether you want to test a web application or not (e.g.
with |
If you want a web application to start up and listen on its normal port, so you can test
it with HTTP (e.g. using RestTemplate
), annotate your test class (or one of its
superclasses) with @WebIntegrationTest
. This can be very useful because it means you can
test the full stack of your application, but also inject its components into the test
class and use them to assert the internal state of the application after an HTTP
interaction. For example:
@RunWith(SpringJUnit4ClassRunner.class) @SpringApplicationConfiguration(classes = SampleDataJpaApplication.class) @WebIntegrationTest public class CityRepositoryIntegrationTests { @Autowired CityRepository repository; RestTemplate restTemplate = new TestRestTemplate(); // ... interact with the running server }
Note | |
---|---|
Spring’s test framework will cache application contexts between tests. Therefore, as long as your tests share the same configuration, the time consuming process of starting and stopping the server will only happen once, regardless of the number of tests that actually run. |
To change the port you can add environment properties to @WebIntegrationTest
as colon-
or equals-separated name-value pairs, e.g. @WebIntegrationTest("server.port:9000")
.
Additionally you can set the server.port
and management.port
properties to 0
in order to run your integration tests using random ports. For example:
@RunWith(SpringJUnit4ClassRunner.class) @SpringApplicationConfiguration(classes = MyApplication.class) @WebIntegrationTest({"server.port=0", "management.port=0"}) public class SomeIntegrationTests { // ... }
See Section 67.5, “Discover the HTTP port at runtime” for a description of how you can discover the actual port that was allocated for the duration of the tests.
If you wish to use Spock to test a Spring Boot application you should add a dependency
on Spock’s spock-spring
module to your application’s build. spock-spring
integrates
Spring’s test framework into Spock.
Note | |
---|---|
The annotations described above
can be used with Spock, i.e. you can annotate your |
A few test utility classes are packaged as part of spring-boot
that are generally
useful when testing your application.
ConfigFileApplicationContextInitializer
is an ApplicationContextInitializer
that
can apply to your tests to load Spring Boot application.properties
files. You can use
this when you don’t need the full features provided by @SpringApplicationConfiguration
.
@ContextConfiguration(classes = Config.class, initializers = ConfigFileApplicationContextInitializer.class)
EnvironmentTestUtils
allows you to quickly add properties to a
ConfigurableEnvironment
or ConfigurableApplicationContext
. Simply call it with
key=value
strings:
EnvironmentTestUtils.addEnvironment(env, "org=Spring", "name=Boot");
OutputCapture
is a JUnit Rule
that you can use to capture System.out
and
System.err
output. Simply declare the capture as a @Rule
then use toString()
for assertions:
import org.junit.Rule; import org.junit.Test; import org.springframework.boot.test.OutputCapture; import static org.hamcrest.Matchers.*; import static org.junit.Assert.*; public class MyTest { @Rule public OutputCapture capture = new OutputCapture(); @Test public void testName() throws Exception { System.out.println("Hello World!"); assertThat(capture.toString(), containsString("World")); } }
TestRestTemplate
is a convenience subclass of Spring’s RestTemplate
that is useful in
integration tests. You can get a vanilla template or one that sends Basic HTTP
authentication (with a username and password). In either case the template will behave
in a test-friendly way: not following redirects (so you can assert the response location),
ignoring cookies (so the template is stateless), and not throwing exceptions on
server-side errors. It is recommended, but not mandatory, to use Apache HTTP Client
(version 4.3.2 or better), and if you have that on your classpath the TestRestTemplate
will respond by configuring the client appropriately.
public class MyTest { RestTemplate template = new TestRestTemplate(); @Test public void testRequest() throws Exception { HttpHeaders headers = template.getForEntity("http://myhost.com", String.class).getHeaders(); assertThat(headers.getLocation().toString(), containsString("myotherhost")); } }
If you work in a company that develops shared libraries, or if you work on an open-source or commercial library, you might want to develop your own auto-configuration. Auto-configuration classes can be bundled in external jars and still be picked-up by Spring Boot.
Under the hood, auto-configuration is implemented with standard @Configuration
classes.
Additional @Conditional
annotations are used to constrain when the auto-configuration
should apply. Usually auto-configuration classes use @ConditionalOnClass
and
@ConditionalOnMissingBean
annotations. This ensures that auto-configuration only applies
when relevant classes are found and when you have not declared your own @Configuration
.
You can browse the source code of spring-boot-autoconfigure
to see the @Configuration
classes that we provide (see the META-INF/spring.factories
file).
Spring Boot checks for the presence of a META-INF/spring.factories
file within your
published jar. The file should list your configuration classes under the
EnableAutoConfiguration
key.
org.springframework.boot.autoconfigure.EnableAutoConfiguration=\ com.mycorp.libx.autoconfigure.LibXAutoConfiguration,\ com.mycorp.libx.autoconfigure.LibXWebAutoConfiguration
You can use the
@AutoConfigureAfter
or
@AutoConfigureBefore
annotations if your configuration needs to be applied in a specific order. For example, if
you provide web-specific configuration, your class may need to be applied after
WebMvcAutoConfiguration
.
You almost always want to include one or more @Conditional
annotations on your
auto-configuration class. The @ConditionalOnMissingBean
is one common example that is
used to allow developers to ‘override’ auto-configuration if they are not happy with
your defaults.
Spring Boot includes a number of @Conditional
annotations that you can reuse in your own
code by annotating @Configuration
classes or individual @Bean
methods.
The @ConditionalOnClass
and @ConditionalOnMissingClass
annotations allows
configuration to be included based on the presence or absence of specific classes. Due to
the fact that annotation metadata is parsed using ASM you can
actually use the value
attribute to refer to the real class, even though that class
might not actually appear on the running application classpath. You can also use the
name
attribute if you prefer to specify the class name using a String
value.
The @ConditionalOnBean
and @ConditionalOnMissingBean
annotations allow configurations
to be included based on the presence or absence of specific beans. You can use the value
attribute to specify beans by type, or name
to specify beans by name. The search
attribute allows you to limit the ApplicationContext
hierarchy that should be considered
when searching for beans.
Note | |
---|---|
|
The @ConditionalOnProperty
annotation allows configuration to be included based on a
Spring Environment property. Use the prefix
and name
attributes to specify the
property that should be checked. By default any property that exists and is not equal to
false
will be matched. You can also create more advanced checks using the havingValue
and matchIfMissing
attributes.
The @ConditionalOnResource
annotation allows configuration to be included only when a
specific resource is present. Resources can be specified using the usual Spring
conventions, for example, file:/home/user/test.dat
.
The @ConditionalOnWebApplication
and @ConditionalOnNotWebApplication
annotations
allow configuration to be included depending on whether the application is a 'web
application'. A web application is any application that is using a Spring
WebApplicationContext
, defines a session
scope or has a StandardServletEnvironment
.
The @ConditionalOnExpression
annotation allows configuration to be included based on the
result of a SpEL expression.
Spring Boot provides WebSockets auto-configuration for embedded Tomcat (8 and 7), Jetty 9 and Undertow. If you’re deploying a war file to a standalone container, Spring Boot assumes that the container will be responsible for the configuration of its WebSocket support.
Spring Framework provides rich WebSocket support that can
be easily accessed via the spring-boot-starter-websocket
module.
If you want to learn more about any of the classes discussed in this section you can check out the Spring Boot API documentation or you can browse the source code directly. If you have specific questions, take a look at the how-to section.
If you are comfortable with Spring Boot’s core features, you can carry on and read about production-ready features.
Spring Boot includes a number of additional features to help you monitor and manage your application when it’s pushed to production. You can choose to manage and monitor your application using HTTP endpoints, with JMX or even by remote shell (SSH or Telnet). Auditing, health and metrics gathering can be automatically applied to your application.
The spring-boot-actuator
module provides all of
Spring Boot’s production-ready features. The simplest way to enable the features is to add
a dependency to the spring-boot-starter-actuator
‘Starter POM’.
To add the actuator to a Maven based project, add the following ‘starter’ dependency:
<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> </dependencies>
For Gradle, use the declaration:
dependencies {
compile("org.springframework.boot:spring-boot-starter-actuator")
}
Actuator endpoints allow you to monitor and interact with your application. Spring Boot
includes a number of built-in endpoints and you can also add your own. For example the
health
endpoint provides basic application health information.
The way that endpoints are exposed will depend on the type of technology that you choose.
Most applications choose HTTP monitoring, where the ID of the endpoint is mapped
to a URL. For example, by default, the health
endpoint will be mapped to /health
.
The following endpoints are available:
ID | Description | Sensitive |
---|---|---|
| Displays an auto-configuration report showing all auto-configuration candidates and the reason why they ‘were’ or ‘were not’ applied. | true |
| Displays a complete list of all the Spring beans in your application. | true |
| Displays a collated list of all | true |
| Performs a thread dump. | true |
| Exposes properties from Spring’s | true |
| Shows any Flyway database migrations that have been applied. | true |
| Shows application health information (when the application is secure, a simple ‘status’ when accessed over an unauthenticated connection or full message details when authenticated). | false |
| Displays arbitrary application info. | false |
| Shows any Liquibase database migrations that have been applied. | true |
| Returns the contents of the logfile (if | true |
| Shows ‘metrics’ information for the current application. | true |
| Displays a collated list of all | true |
| Allows the application to be gracefully shutdown (not enabled by default). | true |
| Displays trace information (by default the last few HTTP requests). | true |
Note | |
---|---|
Depending on how an endpoint is exposed, the |
Endpoints can be customized using Spring properties. You can change if an endpoint is
enabled
, if it is considered sensitive
and even its id
.
For example, here is an application.properties
that changes the sensitivity and id
of the beans
endpoint and also enables shutdown
.
endpoints.beans.id=springbeans endpoints.beans.sensitive=false endpoints.shutdown.enabled=true
Note | |
---|---|
The prefix ‟ |
By default, all endpoints except for shutdown
are enabled. If you prefer to
specifically “opt-in” endpoint enablement you can use the endpoints.enabled
property.
For example, the following will disable all endpoints except for info
:
endpoints.enabled=false endpoints.info.enabled=true
If Spring HATEOAS is on the classpath (e.g.
through the spring-boot-starter-hateoas
or if you are using
Spring Data REST) then the HTTP endpoints
from the Actuator are enhanced with hypermedia links, and a “discovery page” is added
with links to all the endpoints. The “discovery page” is actually an endpoint itself,
so it can be disabled along with the rest of the hypermedia by setting
endpoints.links.enabled=false
. If it is not explicitly disabled the links
endpoint renders a JSON object with a link for each other endpoint, and the default
path is the same as the management.content-path
(so “/” by default).
Note | |
---|---|
if there is a static home page (“index.html”) in your application and the links
endpoint is registered with its default path (“/”) then content negotiation will kick in
to determine which content is shown to a client that requests the home page (the
links will show only if the client accepts |
If the HAL Browser is on the classpath
via its webjar (org.webjars:hal-browser
), or via the spring-data-hal-browser
then
the default home page for HTML clients will be the HAL Browser. This is also exposed via
an endpoint (“hal”) so it can be disabled and have its path explicitly configured like
the other endpoints.
If you add a @Bean
of type Endpoint
then it will automatically be exposed over JMX and
HTTP (if there is an server available). An HTTP endpoints can be customized further by
creating a bean of type MvcEndpoint
. Your MvcEndpoint
is not a @Controller
but it
can use @RequestMapping
(and @Managed*
) to expose resources.
Tip | |
---|---|
If you are doing this as a library feature consider adding a configuration class to
|
Health information can be used to check the status of your running application. It is
often used by monitoring software to alert someone if a production system goes down.
The default information exposed by the health
endpoint depends on how it is accessed.
For an unauthenticated connection in a secure application a simple ‘status’ message is
returned, and for an authenticated connection additional details are also displayed (see
Section 45.6, “HTTP health endpoint access restrictions” for HTTP details).
Health information is collected from all
HealthIndicator
beans defined
in your ApplicationContext
. Spring Boot includes a number of auto-configured
HealthIndicators
and you can also write your own.
Information returned by HealthIndicators
is often somewhat sensitive in nature. For
example, you probably don’t want to publish details of your database server to the
world. For this reason, by default, only the health status is exposed over an
unauthenticated HTTP connection. If you are happy for complete health information to always
be exposed you can set endpoints.health.sensitive
to false
.
Health responses are also cached to prevent “denial of service” attacks. Use the
endpoints.health.time-to-live
property if you want to change the default cache period
of 1000 milliseconds.
The following HealthIndicators
are auto-configured by Spring Boot when appropriate:
Name | Description |
---|---|
Checks for low disk space. | |
Checks that a connection to | |
Checks that a Mongo database is up. | |
Checks that a Rabbit server is up. | |
Checks that a Redis server is up. | |
Checks that a Solr server is up. |
To provide custom health information you can register Spring beans that implement the
HealthIndicator
interface.
You need to provide an implementation of the health()
method and return a Health
response. The Health
response should include a status and can optionally include
additional details to be displayed.
import org.springframework.boot.actuate.health.HealthIndicator; import org.springframework.stereotype.Component; @Component public class MyHealth implements HealthIndicator { @Override public Health health() { int errorCode = check(); // perform some specific health check if (errorCode != 0) { return Health.down().withDetail("Error Code", errorCode).build(); } return Health.up().build(); } }
In addition to Spring Boot’s predefined Status
types, it is also possible for Health
to return a custom Status
that represents a
new system state. In such cases a custom implementation of the
HealthAggregator
interface also needs to be provided, or the default implementation has to be configured
using the management.health.status.order
configuration property.
For example, assuming a new Status
with code FATAL
is being used in one of your
HealthIndicator
implementations. To configure the severity order add the following
to your application properties:
management.health.status.order=DOWN, OUT_OF_SERVICE, UNKNOWN, UP
You might also want to register custom status mappings with the HealthMvcEndpoint
if you access the health endpoint over HTTP. For example you could map FATAL
to
HttpStatus.SERVICE_UNAVAILABLE
.
You can customize the data exposed by the info
endpoint by setting info.*
Spring
properties. All Environment
properties under the info key will be automatically
exposed. For example, you could add the following to your application.properties
:
info.app.name=MyService info.app.description=My awesome service info.app.version=1.0.0
Rather than hardcoding some properties that are also specified in your project’s build configuration, you can automatically expand info properties using the existing build configuration instead. This is possible in both Maven and Gradle.
You can automatically expand info properties from the Maven project using resource
filtering. If you use the spring-boot-starter-parent
you can then refer to your
Maven ‘project properties’ via @..@
placeholders, e.g.
project.artifactId=myproject project.name=Demo project.version=X.X.X.X project.description=Demo project for info endpoint info.build.artifact[email protected]@ info.build.name[email protected]@ info.build.description[email protected]@ info.build.version[email protected]@
Note | |
---|---|
In the above example we used |
Tip | |
---|---|
The |
If you don’t use the starter parent, in your pom.xml
you need (inside the <build/>
element):
<resources> <resource> <directory>src/main/resources</directory> <filtering>true</filtering> </resource> </resources>
and (inside <plugins/>
):
<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-resources-plugin</artifactId> <version>2.6</version> <configuration> <delimiters> <delimiter>@</delimiter> </delimiters> </configuration> </plugin>
You can automatically expand info properties from the Gradle project by configuring
the Java plugin’s processResources
task to do so:
processResources { expand(project.properties) }
You can then refer to your Gradle project’s properties via placeholders, e.g.
info.build.name=${name} info.build.description=${description} info.build.version=${version}
Note | |
---|---|
Gradle’s |
Another useful feature of the info
endpoint is its ability to publish information
about the state of your git
source code repository when the project was built. If a
git.properties
file is contained in your jar the git.branch
and git.commit
properties will be loaded.
For Maven users the spring-boot-starter-parent
POM includes a pre-configured plugin to
generate a git.properties
file. Simply add the following declaration to your POM:
<build> <plugins> <plugin> <groupId>pl.project13.maven</groupId> <artifactId>git-commit-id-plugin</artifactId> </plugin> </plugins> </build>
A similar gradle-git
plugin is also available
for Gradle users, although a little more work is required to generate the properties file.
If you are developing a Spring MVC application, Spring Boot Actuator will auto-configure
all enabled endpoints to be exposed over HTTP. The default convention is to use the
id
of the endpoint as the URL path. For example, health
is exposed as /health
.
If you add ‘Spring Security’ to your project, all sensitive endpoints exposed over HTTP
will be protected. By default ‘basic’ authentication will be used with the username
user
and a generated password (which is printed on the console when the application
starts).
Tip | |
---|---|
Generated passwords are logged as the application starts. Search for ‘Using default security password’. |
You can use Spring properties to change the username and password and to change the
security role required to access the endpoints. For example, you might set the following
in your application.properties
:
security.user.name=admin security.user.password=secret management.security.role=SUPERUSER
Tip | |
---|---|
If you don’t use Spring Security and your HTTP endpoints are exposed publicly,
you should carefully consider which endpoints you enable. See
Section 44.1, “Customizing endpoints” for details of how you can set
|
Sometimes it is useful to group all management endpoints under a single path. For example,
your application might already use /info
for another purpose. You can use the
management.context-path
property to set a prefix for your management endpoint:
management.context-path=/manage
The application.properties
example above will change the endpoint from /{id}
to
/manage/{id}
(e.g. /manage/info
).
Exposing management endpoints using the default HTTP port is a sensible choice for cloud based deployments. If, however, your application runs inside your own data center you may prefer to expose endpoints using a different HTTP port.
The management.port
property can be used to change the HTTP port.
management.port=8081
Since your management port is often protected by a firewall, and not exposed to the public you might not need security on the management endpoints, even if your main application is secure. In that case you will have Spring Security on the classpath, and you can disable management security like this:
management.security.enabled=false
(If you don’t have Spring Security on the classpath then there is no need to explicitly disable the management security in this way, and it might even break the application.)
You can customize the address that the management endpoints are available on by
setting the management.address
property. This can be useful if you want to
listen only on an internal or ops-facing network, or to only listen for connections from
localhost
.
Note | |
---|---|
You can only listen on a different address if the port is different to the main server port. |
Here is an example application.properties
that will not allow remote management
connections:
management.port=8081 management.address=127.0.0.1
If you don’t want to expose endpoints over HTTP you can set the management port to -1
:
management.port=-1
The information exposed by the health endpoint varies depending on whether or not it’s
accessed anonymously, and whether or not the enclosing application is secure.
By default, when accessed anonymously in a secure application, any details about the
server’s health are hidden and the endpoint will simply indicate whether or not the server
is up or down. Furthermore, when accessed anonymously, the response is cached for a
configurable period to prevent the endpoint being used in a denial of service attack.
The endpoints.health.time-to-live
property is used to configure the caching period in
milliseconds. It defaults to 1000, i.e. one second.
The above-described restrictions can be enhanced, thereby allowing only authenticated
users full access to the health endpoint in a secure application. To do so, set
endpoints.health.sensitive
to true
. Here’s a summary of behavior (with default
sensitive
flag value “false” indicated in bold):
Secure | Sensitive | Unauthenticated | Authenticated |
---|---|---|---|
false | false | Full content | Full content |
false | true | Status only | Full content |
true | false | Status only | Full content |
true | true | No content | Full content |
Java Management Extensions (JMX) provide a standard mechanism to monitor and manage
applications. By default Spring Boot will expose management endpoints as JMX MBeans
under the org.springframework.boot
domain.
The name of the MBean is usually generated from the id
of the endpoint. For example
the health
endpoint is exposed as org.springframework.boot/Endpoint/healthEndpoint
.
If your application contains more than one Spring ApplicationContext
you may find that
names clash. To solve this problem you can set the endpoints.jmx.unique-names
property
to true
so that MBean names are always unique.
You can also customize the JMX domain under which endpoints are exposed. Here is an
example application.properties
:
endpoints.jmx.domain=myapp endpoints.jmx.unique-names=true
If you don’t want to expose endpoints over JMX you can set the endpoints.jmx.enabled
property to false
:
endpoints.jmx.enabled=false
Jolokia is a JMX-HTTP bridge giving an alternative method of accessing JMX beans. To
use Jolokia, simply include a dependency to org.jolokia:jolokia-core
. For example,
using Maven you would add the following:
<dependency> <groupId>org.jolokia</groupId> <artifactId>jolokia-core</artifactId> </dependency>
Jolokia can then be accessed using /jolokia
on your management HTTP server.
Jolokia has a number of settings that you would traditionally configure using servlet
parameters. With Spring Boot you can use your application.properties
, simply prefix the
parameter with jolokia.config.
:
jolokia.config.debug=true
Spring Boot supports an integrated Java shell called ‘CRaSH’. You can use CRaSH to
ssh
or telnet
into your running application. To enable remote shell support, add
the following dependency to your project:
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-remote-shell</artifactId> </dependency>
Tip | |
---|---|
If you want to also enable telnet access you will additionally need a dependency
on |
By default the remote shell will listen for connections on port 2000
. The default user
is user
and the default password will be randomly generated and displayed in the log
output. If your application is using Spring Security, the shell will use
the same configuration by default. If not, a simple
authentication will be applied and you should see a message like this:
Using default password for shell access: ec03e16c-4cf4-49ee-b745-7c8255c1dd7e
Linux and OSX users can use ssh
to connect to the remote shell, Windows users can
download and install PuTTY.
$ ssh -p 2000 user@localhost user@localhost's password: . ____ _ __ _ _ /\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \ ( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \ \\/ ___)| |_)| | | | | || (_| | ) ) ) ) ' |____| .__|_| |_|_| |_\__, | / / / / =========|_|==============|___/=/_/_/_/ :: Spring Boot :: (v1.3.0.M2) on myhost
Type help
for a list of commands. Spring Boot provides metrics
, beans
, autoconfig
and endpoint
commands.
You can use the shell.auth.simple.user.name
and shell.auth.simple.user.password
properties
to configure custom connection credentials. It is also possible to use a
‘Spring Security’ AuthenticationManager
to handle login duties. See the
CrshAutoConfiguration
and ShellProperties
Javadoc for full details.
The remote shell can be extended in a number of interesting ways.
You can write additional shell commands using Groovy or Java (see the CRaSH documentation for details). By default Spring Boot will search for commands in the following locations:
classpath*:/commands/**
classpath*:/crash/commands/**
Tip | |
---|---|
You can change the search path by settings a |
Here is a simple ‘hello’ command that could be loaded from
src/main/resources/commands/hello.groovy
package commands import org.crsh.cli.Command import org.crsh.cli.Usage import org.crsh.command.InvocationContext class hello { @Usage("Say Hello") @Command def main(InvocationContext context) { return "Hello" } }
Spring Boot adds some additional attributes to InvocationContext
that you can access
from your command:
Attribute Name | Description |
---|---|
| The version of Spring Boot |
| The version of the core Spring Framework |
| Access to the Spring |
| Access to the Spring |
In addition to new commands, it is also possible to extend other CRaSH shell features.
All Spring Beans that extend org.crsh.plugin.CRaSHPlugin
will be automatically
registered with the shell.
For more information please refer to the CRaSH reference documentation.
Spring Boot Actuator includes a metrics service with ‘gauge’ and ‘counter’ support.
A ‘gauge’ records a single value; and a ‘counter’ records a delta (an increment or
decrement). Spring Boot Actuator also provides a
PublicMetrics
interface that
you can implement to expose metrics that you cannot record via one of those two
mechanisms. Look at SystemPublicMetrics
for an example.
Metrics for all HTTP requests are automatically recorded, so if you hit the metrics
endpoint you should see a response similar to this:
{ "counter.status.200.root": 20, "counter.status.200.metrics": 3, "counter.status.200.star-star": 5, "counter.status.401.root": 4, "gauge.response.star-star": 6, "gauge.response.root": 2, "gauge.response.metrics": 3, "classes": 5808, "classes.loaded": 5808, "classes.unloaded": 0, "heap": 3728384, "heap.committed": 986624, "heap.init": 262144, "heap.used": 52765, "mem": 986624, "mem.free": 933858, "processors": 8, "threads": 15, "threads.daemon": 11, "threads.peak": 15, "uptime": 494836, "instance.uptime": 489782, "datasource.primary.active": 5, "datasource.primary.usage": 0.25 }
Here we can see basic memory
, heap
, class loading
, processor
and thread pool
information along with some HTTP metrics. In this instance the root
(‘/’) and /metrics
URLs have returned HTTP 200
responses 20
and 3
times respectively. It also appears
that the root
URL returned HTTP 401
(unauthorized) 4
times. The double asterix (star-star
)
comes from a request matched by Spring MVC as /**
(normally a static resource).
The gauge
shows the last response time for a request. So the last request to root
took
2ms
to respond and the last to /metrics
took 3ms
.
Note | |
---|---|
In this example we are actually accessing the endpoint over HTTP using the
|
The following system metrics are exposed by Spring Boot:
mem
)mem.free
)processors
)uptime
)instance.uptime
)systemload.average
)heap
, heap.committed
, heap.init
, heap.used
)threads
, thread.peak
, thread.daemon
)classes
, classes.loaded
, classes.unloaded
)gc.xxx.count
, gc.xxx.time
)The following metrics are exposed for each supported DataSource
defined in your
application:
datasource.xxx.active
)datasource.xxx.usage
).All data source metrics share the datasource.
prefix. The prefix is further qualified
for each data source:
@Primary
amongst the existing ones), the prefix is
datasource.primary
.DataSource
, the prefix is the name of the bean
without DataSource
(i.e. datasource.batch
for batchDataSource
).It is possible to override part or all of those defaults by registering a bean with a
customized version of DataSourcePublicMetrics
. By default, Spring Boot provides metadata
for all supported data sources; you can add additional DataSourcePoolMetadataProvider
beans if your favorite data source isn’t supported out of the box. See
DataSourcePoolMetadataProvidersConfiguration
for examples.
The following metrics are exposed for each supported cache defined in your application:
cache.xxx.size
)cache.xxx.hit.ratio
)cache.xxx.miss.ratio
)Note | |
---|---|
Cache providers do not expose the hit/miss ratio in a consistent way. While some expose an aggregated value (i.e. the hit ratio since the last time the stats were cleared), others expose a temporal value (i.e. the hit ratio of the last second). Check your caching provider documentation for more details. |
If two different cache managers happen to define the same cache, the name of the cache
is prefixed by the name of the CacheManager
bean.
It is possible to override part or all of those defaults by registering a bean with a
customized version of CachePublicMetrics
. By default, Spring Boot provides cache
statistics for EhCache, Hazelcast, Infinispan, JCache and Guava. You can add additional
CacheStatisticsProvider
beans if your favorite caching library isn’t supported out of
the box. See CacheStatisticsAutoConfiguration
for examples.
If you are using Tomcat as your embedded servlet container, session metrics will
automatically be exposed. The httpsessions.active
and httpsessions.max
keys provide
the number of active and maximum sessions.
To record your own metrics inject a
CounterService
and/or
GaugeService
into
your bean. The CounterService
exposes increment
, decrement
and reset
methods; the
GaugeService
provides a submit
method.
Here is a simple example that counts the number of times that a method is invoked:
import org.springframework.beans.factory.annotation.Autowired; import org.springframework.boot.actuate.metrics.CounterService; import org.springframework.stereotype.Service; @Service public class MyService { private final CounterService counterService; @Autowired public MyService(CounterService counterService) { this.counterService = counterService; } public void exampleMethod() { this.counterService.increment("services.system.myservice.invoked"); } }
Tip | |
---|---|
You can use any string as a metric name but you should follow guidelines of your chosen store/graphing technology. Some good guidelines for Graphite are available on Matt Aimonetti’s Blog. |
To add additional metrics that are computed every time the metrics endpoint is invoked,
simply register additional PublicMetrics
implementation bean(s). By default, all such
beans are gathered by the endpoint. You can easily change that by defining your own
MetricsEndpoint
.
The default implementation of GaugeService
and CounterService
provided by Spring Boot
depends on the version of Java that you are using. With Java 8 (or better) the
implementation switches to a high-performance version optimized for fast writes, backed by
atomic in-memory buffers, rather than by the immutable but relatively expensive
Metric<?>
type (counters are approximately 5 times faster and gauges approximately twice
as fast as the repository-based implementations). The Dropwizard metrics services (see
below) are also very efficient even for Java 7 (they have backports of some of the Java 8
concurrency libraries), but they do not record timestamps for metric values. If
performance of metric gathering is a concern then it is always advisable to use one of the
high-performance options, and also to only read metrics infrequently, so that the writes
are buffered locally and only read when needed.
Note | |
---|---|
The old |
Spring Boot provides a couple of implementations of a marker interface called Exporter
which can be used to copy metric readings from the in-memory buffers to a place where they
can be analyzed and displayed. Indeed, if you provide a @Bean
that implements the
MetricWriter
interface and mark it @ExportMetricWriter
, then it will automatically be
hooked up to an Exporter
and fed metric updates every 5 seconds (configured via
spring.metrics.export.delay-millis
). In addition, any MetricReader
that you define and
mark as @ExportMetricReader
will have its values exported by the default exporter.
The default exporter is a MetricCopyExporter
which tries to optimize itself by not
copying values that haven’t changed since it was last called (the optimization can be
switched off using a flag spring.metrics.export.send-latest
). Note also that the
Dropwizard MetricRegistry
has no support for timestamps, so the optimization is not
available if you are using Dropwizard metrics (all metrics will be copied on every tick).
The default values for the export trigger (delay-millis
, includes
, excludes
and send-latest
) can be set as spring.metrics.export.*
. Individual
values for specific MetricWriters
can be set as
spring.metrics.export.triggers.<name>.*
where <name>
is a bean name (or pattern for
matching bean names).
If you provide a @Bean
of type RedisMetricRepository
and mark it @ExportMetricWriter
the metrics are exported to a Redis cache for aggregation. The RedisMetricRepository
has
two important parameters to configure it for this purpose: prefix
and key
(passed into
its constructor). It is best to use a prefix that is unique to the application instance
(e.g. using a random value and maybe the logical name of the application to make it
possible to correlate with other instances of the same application). The “key” is used
to keep a global index of all metric names, so it should be unique “globally”, whatever
that means for your system (e.g. two instances of the same system could share a Redis cache
if they have distinct keys).
Example:
@Bean @ExportMetricWriter MetricWriter metricWriter(MetricExportProperties export) { return new RedisMetricRepository(connectionFactory, export.getRedis().getPrefix(), export.getRedis().getKey()); }
application.properties.
spring.metrics.export.redis.prefix: metrics.mysystem.${spring.application.name:application}.${random.value:0000} spring.metrics.export.redis.key: keys.metrics.mysystem
The prefix is constructed with the application name and id at the end, so it can easily be used to identify a group of processes with the same logical name later.
Note | |
---|---|
It’s important to set both the |
Tip | |
---|---|
The example above uses |
If you provide a @Bean
of type OpenTsdbHttpMetricWriter
and mark it
@ExportMetricWriter
metrics are exported to Open TSDB for
aggregation. The OpenTsdbHttpMetricWriter
has a url
property that you need to set
to the Open TSDB “/put” endpoint, e.g. localhost:4242/api/put
). It also has a
namingStrategy
that you can customize or configure to make the metrics match the data
structure you need on the server. By default it just passes through the metric name as an
Open TSDB metric name, and adds the tags “domain” (with value
“org.springframework.metrics”) and “process” (with the value equal to the object hash
of the naming strategy). Thus, after running the application and generating some metrics
you can inspect the metrics in the TDB UI (localhost:4242 by default).
Example:
curl localhost:4242/api/query?start=1h-ago&m=max:counter.status.200.root [ { "metric": "counter.status.200.root", "tags": { "domain": "org.springframework.metrics", "process": "b968a76" }, "aggregateTags": [], "dps": { "1430492872": 2, "1430492875": 6 } } ]
If you provide a @Bean
of type StatsdMetricWriter
and mark it @ExportMetricWriter
the metrics are exported to a
statsd server:
@Value("${spring.application.name:application}.${random.value:0000}") private String prefix = "metrics"; @Value("${statsd.host:localhost}") private String host = "localhost"; @Value("${statsd.port:8125}") private int port; @Bean @ExportMetricWriter MetricWriter metricWriter() { return new StatsdMetricWriter(prefix, host, port); }
If you provide a @Bean
of type JmxMetricWriter
marked @ExportMetricWriter
the metrics are exported as MBeans to
the local server (the MBeanExporter
is provided by Spring Boot JMX autoconfiguration as
long as it is switched on). Metrics can then be inspected, graphed, alerted etc. using any
tool that understands JMX (e.g. JConsole or JVisualVM).
Example:
@Bean @ExportMetricWriter MetricWriter metricWriter(MBeanExporter exporter) { return new JmxMetricWriter(exporter); }
Each metric is exported as an individual MBean. The format for the ObjectNames
is given
by an ObjectNamingStrategy
which can be injected into the JmxMetricWriter
(the default
breaks up the metric name and tags the first two period-separated sections in a way that
should make the metrics group nicely in JVisualVM or JConsole).
There is an AggregateMetricReader
that you can use to consolidate metrics from different
physical sources. Sources for the same logical metric just need to publish them with a
period-separated prefix, and the reader will aggregate (by truncating the metric names,
and dropping the prefix). Counters are summed and everything else (i.e. gauges) take their
most recent value.
This is very useful if multiple application instances are feeding to a central (e.g.
Redis) repository and you want to display the results. Particularly recommended in
conjunction with a MetricReaderPublicMetrics
for hooking up to the results to the
“/metrics” endpoint.
Example:
@Autowired private MetricExportProperties export; @Bean public PublicMetrics metricsAggregate() { return new MetricReaderPublicMetrics(aggregatesMetricReader()); } private MetricReader globalMetricsForAggregation() { return new RedisMetricRepository(this.connectionFactory, this.export.getRedis().getAggregatePrefix(), this.export.getRedis().getKey()); } private MetricReader aggregatesMetricReader() { AggregateMetricReader repository = new AggregateMetricReader( globalMetricsForAggregation()); return repository; }
Note | |
---|---|
The example above uses |
Note | |
---|---|
The |
A default MetricRegistry
Spring bean will be created when you declare a dependency to
the io.dropwizard.metrics:metric-core
library; you can also register you own @Bean
instance if you need customizations. Users of the
Dropwizard ‘Metrics’ library will find that
Spring Boot metrics are automatically published to com.codahale.metrics.MetricRegistry
.
Metrics from the MetricRegistry
are also automatically exposed via the /metrics
endpoint
When Dropwizard metrics are in use, the default CounterService
and GaugeService
are
replaced with a DropwizardMetricServices
, which is a wrapper around the MetricRegistry
(so you can @Autowired
one of those services and use it as normal). You can also create
“special” Dropwizard metrics by prefixing your metric names with the appropriate type
(i.e. timer.*
, histogram.*
for gauges, and meter.*
for counters).
If a MessageChannel
bean called metricsChannel
exists, then a MetricWriter
will be
created that writes metrics to that channel. The writer is automatically hooked up to an
exporter (as for all writers), so all metric values will appear on the channel, and
additional analysis or actions can be taken by subscribers (it’s up to you to provide the
channel and any subscribers you need).
Spring Boot Actuator has a flexible audit framework that will publish events once Spring Security is in play (‘authentication success’, ‘failure’ and ‘access denied’ exceptions by default). This can be very useful for reporting, and also to implement a lock-out policy based on authentication failures.
You can also choose to use the audit services for your own business events. To do that
you can either inject the existing AuditEventRepository
into your own components and
use that directly, or you can simply publish AuditApplicationEvent
via the Spring
ApplicationEventPublisher
(using ApplicationEventPublisherAware
).
Tracing is automatically enabled for all HTTP requests. You can view the trace
endpoint
and obtain basic information about the last few requests:
[{ "timestamp": 1394343677415, "info": { "method": "GET", "path": "/trace", "headers": { "request": { "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", "Connection": "keep-alive", "Accept-Encoding": "gzip, deflate", "User-Agent": "Mozilla/5.0 Gecko/Firefox", "Accept-Language": "en-US,en;q=0.5", "Cookie": "_ga=GA1.1.827067509.1390890128; ..." "Authorization": "Basic ...", "Host": "localhost:8080" }, "response": { "Strict-Transport-Security": "max-age=31536000 ; includeSubDomains", "X-Application-Context": "application:8080", "Content-Type": "application/json;charset=UTF-8", "status": "200" } } } },{ "timestamp": 1394343684465, ... }]
If you need to trace additional events you can inject a
TraceRepository
into your
Spring beans. The add
method accepts a single Map
structure that will be converted to
JSON and logged.
By default an InMemoryTraceRepository
will be used that stores the last 100 events. You
can define your own instance of the InMemoryTraceRepository
bean if you need to expand
the capacity. You can also create your own alternative TraceRepository
implementation
if needed.
In Spring Boot Actuator you can find a couple of classes to create files that are useful for process monitoring:
ApplicationPidFileWriter
creates a file containing the application PID (by default in
the application directory with the file name application.pid
).EmbeddedServerPortFileWriter
creates a file (or files) containing the ports of the
embedded server (by default in the application directory with the file name
application.port
).These writers are not activated by default, but you can enable them in one of the ways described below.
In META-INF/spring.factories
file you can activate the listener(s) that
writes a PID file. Example:
org.springframework.context.ApplicationListener=\ org.springframework.boot.actuate.system.ApplicationPidFileWriter, org.springframework.boot.actuate.system.EmbeddedServerPortFileWriter
If you want to explore some of the concepts discussed in this chapter, you can take a look at the actuator sample applications. You also might want to read about graphing tools such as Graphite.
Otherwise, you can continue on, to read about ‘deployment options’ or jump ahead for some in-depth information about Spring Boot’s build tool plugins.
Spring Boot’s flexible packaging options provide a great deal of choice when it comes to deploying your application. You can easily deploy Spring Boot applications to a variety of cloud platforms, to a container images (such as Docker) or to virtual/real machines.
This section covers some of the more common deployment scenarios.
Spring Boot’s executable jars are ready-made for most popular cloud PaaS (platform-as-a-service) providers. These providers tend to require that you “bring your own container”; they manage application processes (not Java applications specifically), so they need some intermediary layer that adapts your application to the cloud’s notion of a running process.
Two popular cloud providers, Heroku and Cloud Foundry, employ a “buildpack” approach.
The buildpack wraps your deployed code in whatever is needed to start your
application: it might be a JDK and a call to java
, it might be an embedded webserver,
or it might be a full-fledged application server. A buildpack is pluggable, but ideally
you should be able to get by with as few customizations to it as possible.
This reduces the footprint of functionality that is not under your control. It minimizes
divergence between development and production environments.
Ideally, your application, like a Spring Boot executable jar, has everything that it needs to run packaged within it.
In this section we’ll look at what it takes to get the simple application that we developed in the “Getting Started” section up and running in the Cloud.
Cloud Foundry provides default buildpacks that come into play if no other buildpack is
specified. The Cloud Foundry Java buildpack
has excellent support for Spring applications, including Spring Boot. You can deploy
stand-alone executable jar applications, as well as traditional .war
packaged
applications.
Once you’ve built your application (using, for example, mvn clean package
) and
installed the cf
command line tool, simply deploy your application using the cf push
command as follows,
substituting the path to your compiled .jar
. Be sure to have
logged in with your
cf
command line client before pushing an application.
$ cf push acloudyspringtime -p target/demo-0.0.1-SNAPSHOT.jar
See the cf push
documentation for more options. If there is a Cloud Foundry
manifest.yml
file present in the same directory, it will be consulted.
Note | |
---|---|
Here we are substituting |
At this point cf
will start uploading your application:
Uploading acloudyspringtime... OK Preparing to start acloudyspringtime... OK -----> Downloaded app package (8.9M) -----> Java Buildpack source: system -----> Downloading Open JDK 1.7.0_51 from .../x86_64/openjdk-1.7.0_51.tar.gz (1.8s) Expanding Open JDK to .java-buildpack/open_jdk (1.2s) -----> Downloading Spring Auto Reconfiguration from 0.8.7 .../auto-reconfiguration-0.8.7.jar (0.1s) -----> Uploading droplet (44M) Checking status of app 'acloudyspringtime'... 0 of 1 instances running (1 starting) ... 0 of 1 instances running (1 down) ... 0 of 1 instances running (1 starting) ... 1 of 1 instances running (1 running) App started
Congratulations! The application is now live!
It’s easy to then verify the status of the deployed application:
$ cf apps Getting applications in ... OK name requested state instances memory disk urls ... acloudyspringtime started 1/1 512M 1G acloudyspringtime.cfapps.io ...
Once Cloud Foundry acknowledges that your application has been deployed, you should be
able to hit the application at the URI given, in this case
acloudyspringtime.cfapps.io/
.
By default, metadata about the running application as well as service connection
information is exposed to the application as environment variables (for example:
$VCAP_SERVICES
). This architecture decision is due to Cloud Foundry’s polyglot
(any language and platform can be supported as a buildpack) nature; process-scoped
environment variables are language agnostic.
Environment variables don’t always make for the easiest API so Spring Boot automatically
extracts them and flattens the data into properties that can be accessed through
Spring’s Environment
abstraction:
@Component class MyBean implements EnvironmentAware { private String instanceId; @Override public void setEnvironment(Environment environment) { this.instanceId = environment.getProperty("vcap.application.instance_id"); } // ... }
All Cloud Foundry properties are prefixed with vcap
. You can use vcap properties to
access application information (such as the public URL of the application) and service
information (such as database credentials). See VcapApplicationListener
Javadoc for
complete details.
Tip | |
---|---|
The Spring Cloud Connectors project
is a better fit for tasks such as configuring a DataSource. Spring Boot includes
auto-configuration support and a |
Heroku is another popular PaaS platform. To customize Heroku builds, you provide a
Procfile
, which provides the incantation required to deploy an application. Heroku
assigns a port
for the Java application to use and then ensures that routing to the
external URI works.
You must configure your application to listen on the correct port. Here’s the Procfile
for our starter REST application:
web: java -Dserver.port=$PORT -jar target/demo-0.0.1-SNAPSHOT.jar
Spring Boot makes -D
arguments available as properties accessible from a Spring
Environment
instance. The server.port
configuration property is fed to the embedded
Tomcat, Jetty or Undertow instance which then uses it when it starts up. The $PORT
environment variable is assigned to us by the Heroku PaaS.
Heroku by default will use Java 1.8. This is fine as long as your Maven or Gradle build
is set to use the same version (Maven users can use the java.version property). If you
want to use JDK 1.7, create a new file adjacent to your pom.xml
and Procfile
,
called system.properties
. In this file add the following:
java.runtime.version=1.7
This should be everything you need. The most common workflow for Heroku deployments is to
git push
the code to production.
$ git push heroku master Initializing repository, done. Counting objects: 95, done. Delta compression using up to 8 threads. Compressing objects: 100% (78/78), done. Writing objects: 100% (95/95), 8.66 MiB | 606.00 KiB/s, done. Total 95 (delta 31), reused 0 (delta 0) -----> Java app detected -----> Installing OpenJDK 1.8... done -----> Installing Maven 3.3.1... done -----> Installing settings.xml... done -----> Executing: mvn -B -DskipTests=true clean install [INFO] Scanning for projects... Downloading: http://repo.spring.io/... Downloaded: http://repo.spring.io/... (818 B at 1.8 KB/sec) .... Downloaded: http://s3pository.heroku.com/jvm/... (152 KB at 595.3 KB/sec) [INFO] Installing /tmp/build_0c35a5d2-a067-4abc-a232-14b1fb7a8229/target/... [INFO] Installing /tmp/build_0c35a5d2-a067-4abc-a232-14b1fb7a8229/pom.xml ... [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 59.358s [INFO] Finished at: Fri Mar 07 07:28:25 UTC 2014 [INFO] Final Memory: 20M/493M [INFO] ------------------------------------------------------------------------ -----> Discovering process types Procfile declares types -> web -----> Compressing... done, 70.4MB -----> Launching... done, v6 http://agile-sierra-1405.herokuapp.com/ deployed to Heroku To [email protected]:agile-sierra-1405.git * [new branch] master -> master
Your application should now be up and running on Heroku.
Openshift is the RedHat public (and enterprise) PaaS solution.
Like Heroku, it works by running scripts triggered by git commits, so you can script
the launching of a Spring Boot application in pretty much any way you like as long as the
Java runtime is available (which is a standard feature you can ask for at Openshift).
To do this you can use the
DIY Cartridge and hooks in your
repository under .openshift/action_scripts
:
The basic model is to:
pre_build
hook
(Java and Maven are installed by default, Gradle is not)Use a build
hook to build your jar (using Maven or Gradle), e.g.
#!/bin/bash cd $OPENSHIFT_REPO_DIR mvn package -s .openshift/settings.xml -DskipTests=true
Add a start
hook that calls java -jar …
#!/bin/bash cd $OPENSHIFT_REPO_DIR nohup java -jar target/*.jar --server.port=${OPENSHIFT_DIY_PORT} --server.address=${OPENSHIFT_DIY_IP} &
Use a stop
hook (since the start is supposed to return cleanly), e.g.
#!/bin/bash source $OPENSHIFT_CARTRIDGE_SDK_BASH PID=$(ps -ef | grep java.*\.jar | grep -v grep | awk '{ print $2 }') if [ -z "$PID" ] then client_result "Application is already stopped" else kill $PID fi
Embed service bindings from environment variables provided by the platform
in your application.properties
, e.g.
spring.datasource.url: jdbc:mysql://${OPENSHIFT_MYSQL_DB_HOST}:${OPENSHIFT_MYSQL_DB_PORT}/${OPENSHIFT_APP_NAME} spring.datasource.username: ${OPENSHIFT_MYSQL_DB_USERNAME} spring.datasource.password: ${OPENSHIFT_MYSQL_DB_PASSWORD}
There’s a blog on running Gradle in Openshift on their website that will get you started with a gradle build to run the app.
Google App Engine is tied to the Servlet 2.5 API, so you can’t deploy a Spring Application there without some modifications. See the Servlet 2.5 section of this guide.
In additional to running Spring Boot applications using java -jar
it is also possible
to make fully executable applications for Unix systems (Linux, OSX, FreeBSD etc).
This makes it very easy to install and manage Spring Boot applications in common
production environments. As long as you are generating ‘fully executable’ jars from your
build, and you are not using a custom embeddedLaunchScript
, the following techniques
can be used.
To create a ‘fully executable’ jar with Maven use the following plugin configuration:
<plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <configuration> <executable>true</executable> </configuration> </plugin>
With Gradle, the equivalent configuration would be:
apply plugin: 'spring-boot'
springBoot {
executable = true
}
Note | |
---|---|
Fully executable jars work by embedding an extra script at the front of the file. Not all tools currently accept this format so you may not always be able to use this technique. |
Spring Boot application can be easily started as Unix/Linux services using either init.d
or systemd
.
The default executable script that can be embedded into Spring Boot jars will act as an
init.d
script when it is symlinked to /etc/init.d
. The standard start
, stop
,
restart
and status
commands can be used. The script supports the following features:
/var/run/<appname>/<appname>.pid
/var/log/<appname>.log
Assuming that you have a Spring Boot application installed in /var/myapp
, to install a
Spring Boot application as an init.d
service simply create a symlink:
$ sudo ln -s /var/myapp/myapp.jar /etc/init.d/myapp
Tip | |
---|---|
It is advisable to create a specific user account to run you application. Ensure
that you have set the owner of the jar file using |
Once installed, you can start and stop the service in the usual way. You can also flag the application to start automatically using your standard operating system tools. For example, if you use Debian:
$ update-rc.d myapp defaults <priority>
Systemd is the successor to init.d
scripts, and now being used by many many modern Linux
distributions. Although you can continue to use init.d
script with systemd
, it is also
possible to launch Spring Boot applications using systemd
‘service’ scripts.
For example, to run a Spring Boot application installed in var/myapp
you can add the
following script in /etc/systemd/system/myapp.service
:
[Unit] Description=myapp After=syslog.target [Service] ExecStart=/var/myapp/myapp.jar [Install] WantedBy=multi-user.target
Tip | |
---|---|
Remember to change the |
The script accepts the following parameters as environment variables, so you can change the default behavior in a script or on the command line:
Variable | Description |
---|---|
| The “mode” of operation. The default depends on the way the jar was built, but will
usually be |
| The root name of the pid folder ( |
| The name of the folder to put log files in ( |
| The name of the app. If the jar is run from a symlink the script guesses the app name, but if it is not a symlink, or you want to explicitly set the app name this can be useful. |
| The location of the |
| The explicit location of the jar file, in case the script is being used to launch a jar that it is not actually embedded in. |
| if not empty will set the |
Tip | |
---|---|
With the exception of |
Check out the Cloud Foundry, Heroku and Openshift web sites for more information about the kinds of features that a PaaS can offer. These are just three of the most popular Java PaaS providers, since Spring Boot is so amenable to cloud-based deployment you’re free to consider other providers as well.
The next section goes on to cover the Spring Boot CLI; or you can jump ahead to read about build tool plugins.
The Spring Boot CLI is a command line tool that can be used if you want to quickly develop with Spring. It allows you to run Groovy scripts, which means that you have a familiar Java-like syntax, without so much boilerplate code. You can also bootstrap a new project or write your own command for it.
The Spring Boot CLI can be installed manually; using GVM (the Groovy Environment Manually) or using Homebrew or MacPorts if you are an OSX user. See Section 10.2, “Installing the Spring Boot CLI” in the “Getting started” section for comprehensive installation instructions.
Once you have installed the CLI you can run it by typing spring
. If you run spring
without any arguments, a simple help screen is displayed:
$ spring
usage: spring [--help] [--version]
<command> [<args>]
Available commands are:
run [options] <files> [--] [args]
Run a spring groovy script
... more command help is shown here
You can use help
to get more details about any of the supported commands. For example:
$ spring help run spring run - Run a spring groovy script usage: spring run [options] <files> [--] [args] Option Description ------ ----------- --autoconfigure [Boolean] Add autoconfigure compiler transformations (default: true) --classpath, -cp Additional classpath entries -e, --edit Open the file with the default system editor --no-guess-dependencies Do not attempt to guess dependencies --no-guess-imports Do not attempt to guess imports -q, --quiet Quiet logging -v, --verbose Verbose logging of dependency resolution --watch Watch the specified file for changes
The version
command provides a quick way to check which version of Spring Boot you are
using.
$ spring version Spring CLI v1.3.0.M2
You can compile and run Groovy source code using the run
command. The Spring Boot CLI
is completely self-contained so you don’t need any external Groovy installation.
Here is an example “hello world” web application written in Groovy:
hello.groovy.
@RestController class WebApplication { @RequestMapping("/") String home() { "Hello World!" } }
To compile and run the application type:
$ spring run hello.groovy
To pass command line arguments to the application, you need to use a --
to separate
them from the “spring” command arguments, e.g.
$ spring run hello.groovy -- --server.port=9000
To set JVM command line arguments you can use the JAVA_OPTS
environment variable, e.g.
$ JAVA_OPTS=-Xmx1024m spring run hello.groovy
Standard Groovy includes a @Grab
annotation which allows you to declare dependencies
on a third-party libraries. This useful technique allows Groovy to download jars in the
same way as Maven or Gradle would, but without requiring you to use a build tool.
Spring Boot extends this technique further, and will attempt to deduce which libraries
to “grab” based on your code. For example, since the WebApplication
code above uses
@RestController
annotations, “Tomcat” and “Spring MVC” will be grabbed.
The following items are used as “grab hints”:
Items | Grabs |
---|---|
| JDBC Application. |
| JMS Application. |
| Caching abstraction. |
| JUnit. |
| RabbitMQ. |
| Project Reactor. |
extends | Spock test. |
| Spring Batch. |
| Spring Integration. |
| Spring Mobile. |
| Spring MVC + Embedded Tomcat. |
| Spring Security. |
| Spring Transaction Management. |
Tip | |
---|---|
See subclasses of
|
Spring Boot extends Groovy’s standard @Grab
support by allowing you to specify a dependency
without a group or version, for example @Grab('freemarker')
. This will consult Spring Boot’s
default dependency metadata to deduce the artifact’s group and version. Note that the default
metadata is tied to the version of the CLI that you’re using – it will only change when you move
to a new version of the CLI, putting you in control of when the versions of your dependencies
may change. A table showing the dependencies and their versions that are included in the default
metadata can be found in the appendix.
To help reduce the size of your Groovy code, several import
statements are
automatically included. Notice how the example above refers to @Component
,
@RestController
and @RequestMapping
without needing to use
fully-qualified names or import
statements.
Tip | |
---|---|
Many Spring annotations will work without using |
Unlike the equivalent Java application, you do not need to include a
public static void main(String[] args)
method with your Groovy
scripts. A
SpringApplication
is automatically created, with your compiled code acting as the
source
.
By default, the CLI uses the dependency management declared in spring-boot-dependencies
when resolving @Grab
dependencies. Additional dependency management, that will override
the default dependency management, can be configured using the @DependencyManagementBom
annotation. The annotation’s value should specify the coordinates
(groupId:artifactId:version
) of one or more Maven boms.
For example, the following declaration:
`@DependencyManagementBom("com.example.custom-bom:1.0.0")`
Will pick up custom-bom-1.0.0.pom
in a Maven repository under
com/example/custom-versions/1.0.0/
.
When multiple boms are specified they are applied in the order that they’re declared. For example:
`@DependencyManagementBom(["com.example.custom-bom:1.0.0", "com.example.another-bom:1.0.0"])`
indicates that dependency management in another-bom
will override the dependency
management in custom-bom
.
You can use @DependencyManagementBom
anywhere that you can use @Grab
, however, to
ensure consistent ordering of the dependency management, you can only use
@DependencyManagementBom
at most once in your application. A useful source of
dependency management (that is a superset of Spring Boot’s dependency management) is the
Spring IO Platform, e.g.
@DepenedencyManagementBom('io.spring.platform:platform-bom:1.1.2.RELEASE')
.
The test
command allows you to compile and run tests for your application. Typical
usage looks like this:
$ spring test app.groovy tests.groovy Total: 1, Success: 1, : Failures: 0 Passed? true
In this example, tests.groovy
contains JUnit @Test
methods or Spock Specification
classes. All the common framework annotations and static methods should be available to
you without having to import
them.
Here is the tests.groovy
file that we used above (with a JUnit test):
class ApplicationTests { @Test void homeSaysHello() { assertEquals("Hello World!", new WebApplication().home()) } }
Tip | |
---|---|
If you have more than one test source files, you might prefer to organize them
into a |
You can use “shell globbing” with all commands that accept file input. This allows you to easily use multiple files from a single directory, e.g.
$ spring run *.groovy
This technique can also be useful if you want to segregate your “test” or “spec” code from the main application code:
$ spring test app/*.groovy test/*.groovy
You can use the jar
command to package your application into a self-contained
executable jar file. For example:
$ spring jar my-app.jar *.groovy
The resulting jar will contain the classes produced by compiling the application and all
of the application’s dependencies so that it can then be run using java -jar
. The jar
file will also contain entries from the application’s classpath. You can add explicit
paths to the jar using --include
and --exclude
(both are comma-separated, and both
accept prefixes to the values “+” and “-” to signify that they should be removed from
the defaults). The default includes are
public/**, resources/**, static/**, templates/**, META-INF/**, *
and the default excludes are
.*, repository/**, build/**, target/**, **/*.jar, **/*.groovy
See the output of spring help jar
for more information.
The init
command allows you to create a new project using start.spring.io
without leaving the shell. For example:
$ spring init --dependencies=web,data-jpa my-project Using service at https://start.spring.io Project extracted to '/Users/developer/example/my-project'
This creates a my-project
directory with a Maven-based project using
spring-boot-starter-web
and spring-boot-starter-data-jpa
. You can list the
capabilities of the service using the --list
flag
$ spring init --list ======================================= Capabilities of https://start.spring.io ======================================= Available dependencies: ----------------------- actuator - Actuator: Production ready features to help you monitor and manage your application ... web - Web: Support for full-stack web development, including Tomcat and spring-webmvc websocket - Websocket: Support for WebSocket development ws - WS: Support for Spring Web Services Available project types: ------------------------ gradle-build - Gradle Config [format:build, build:gradle] gradle-project - Gradle Project [format:project, build:gradle] maven-build - Maven POM [format:build, build:maven] maven-project - Maven Project [format:project, build:maven] (default) ...
The init
command supports many options, check the help
output for more details. For
instance, the following command creates a gradle project using Java 8 and war
packaging:
$ spring init --build=gradle --java-version=1.8 --dependencies=websocket --packaging=war sample-app.zip Using service at https://start.spring.io Content saved to 'sample-app.zip'
Spring Boot includes command-line completion scripts for BASH and zsh shells. If you
don’t use either of these shells (perhaps you are a Windows user) then you can use the
shell
command to launch an integrated shell.
$ spring shell
Spring Boot (v1.3.0.M2)
Hit TAB to complete. Type \'help' and hit RETURN for help, and \'exit' to quit.
From inside the embedded shell you can run other commands directly:
$ version Spring CLI v1.3.0.M2
The embedded shell supports ANSI color output as well as tab
completion. If you need
to run a native command you can use the $
prefix. Hitting ctrl-c
will exit the
embedded shell.
You can add extensions to the CLI using the install
command. The command takes one
or more sets of artifact coordinates in the format group:artifact:version
. For example:
$ spring install com.example:spring-boot-cli-extension:1.0.0.RELEASE
In addition to installing the artifacts identified by the coordinates you supply, all of the artifacts' dependencies will also be installed.
To uninstall a dependency use the uninstall
command. As with the install
command, it
takes one or more sets of artifact coordinates in the format group:artifact:version
.
For example:
$ spring uninstall com.example:spring-boot-cli-extension:1.0.0.RELEASE
It will uninstall the artifacts identified by the coordinates you supply and their dependencies.
To uninstall all additional dependencies you can use the --all
option. For example:
$ spring uninstall --all
Spring Framework 4.0 has native support for a beans{}
“DSL” (borrowed from
Grails), and you can embed bean definitions in your Groovy
application scripts using the same format. This is sometimes a good way to include
external features like middleware declarations. For example:
@Configuration class Application implements CommandLineRunner { @Autowired SharedService service @Override void run(String... args) { println service.message } } import my.company.SharedService beans { service(SharedService) { message = "Hello World" } }
You can mix class declarations with beans{}
in the same file as long as they stay at
the top level, or you can put the beans DSL in a separate file if you prefer.
There are some sample groovy scripts available from the GitHub repository that you can use to try out the Spring Boot CLI. There is also extensive javadoc throughout the source code.
If you find that you reach the limit of the CLI tool, you will probably want to look at converting your application to full Gradle or Maven built “groovy project”. The next section covers Spring Boot’s Build tool plugins that you can use with Gradle or Maven.
Spring Boot provides build tool plugins for Maven and Gradle. The plugins offer a variety of features, including the packaging of executable jars. This section provides more details on both plugins, as well as some help should you need to extend an unsupported build system. If you are just getting started, you might want to read “Chapter 13, Build systems” from the Part III, “Using Spring Boot” section first.
The Spring Boot Maven Plugin provides Spring Boot support in Maven, allowing you to package executable jar or war archives and run an application “in-place”. To use it you must be using Maven 3.2 (or better).
Note | |
---|---|
Refer to the Spring Boot Maven Plugin Site for complete plugin documentation. |
To use the Spring Boot Maven Plugin simply include the appropriate XML in the plugins
section of your pom.xml
<?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> <!-- ... --> <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <version>1.3.0.M2</version> <executions> <execution> <goals> <goal>repackage</goal> </goals> </execution> </executions> </plugin> </plugins> </build> </project>
This configuration will repackage a jar or war that is built during the package
phase of
the Maven lifecycle. The following example shows both the repackaged jar, as well as the
original jar, in the target
directory:
$ mvn package $ ls target/*.jar target/myproject-1.0.0.jar target/myproject-1.0.0.jar.original
If you don’t include the <execution/>
configuration as above, you can run the plugin on
its own (but only if the package goal is used as well). For example:
$ mvn package spring-boot:repackage $ ls target/*.jar target/myproject-1.0.0.jar target/myproject-1.0.0.jar.original
If you are using a milestone or snapshot release you will also need to add appropriate
pluginRepository
elements:
<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>
Once spring-boot-maven-plugin
has been included in your pom.xml
it will automatically
attempt to rewrite archives to make them executable using the spring-boot:repackage
goal. You should configure your project to build a jar or war (as appropriate) using the
usual packaging
element:
<?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"> <!-- ... --> <packaging>jar</packaging> <!-- ... --> </project>
Your existing archive will be enhanced by Spring Boot during the package
phase. The
main class that you want to launch can either be specified using a configuration option,
or by adding a Main-Class
attribute to the manifest in the usual way. If you don’t
specify a main class the plugin will search for a class with a
public static void main(String[] args)
method.
To build and run a project artifact, you can type the following:
$ mvn package $ java -jar target/mymodule-0.0.1-SNAPSHOT.jar
To build a war file that is both executable and deployable into an external container you need to mark the embedded container dependencies as “provided”, e.g:
<?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"> <!-- ... --> <packaging>war</packaging> <!-- ... --> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-tomcat</artifactId> <scope>provided</scope> </dependency> <!-- ... --> </dependencies> </project>
Tip | |
---|---|
See the “Section 77.1, “Create a deployable war file”” section for more details on how to create a deployable war file. |
Advanced configuration options and examples are available in the plugin info page.
The Spring Boot Gradle Plugin provides Spring Boot support in Gradle, allowing you to
package executable jar or war archives, run Spring Boot applications and use the
dependency management provided by spring-boot-dependencies
.
To use the Spring Boot Gradle Plugin simply include a buildscript
dependency and apply
the spring-boot
plugin:
buildscript { dependencies { classpath("org.springframework.boot:spring-boot-gradle-plugin:1.3.0.M2") } } apply plugin: 'spring-boot'
If you are using a milestone or snapshot release you will also need to add appropriate
repositories
reference:
buildscript { repositories { maven.url "http://repo.spring.io/snapshot" maven.url "http://repo.spring.io/milestone" } // ... }
The spring-boot
plugin automatically applies the
Dependency Management Plugin and configures in to import
the spring-boot-starter-parent
bom. This provides a similar dependency management
experience to the one that is enjoyed by Maven users. For example, it allows you to omit
version numbers when declaring dependencies that are managed in the bom. To make use of
this functionality, simply declare dependencies in the usual way, but leave the version
number empty:
dependencies { compile("org.springframework.boot:spring-boot-starter-web") compile("org.thymeleaf:thymeleaf-spring4") compile("nz.net.ultraq.thymeleaf:thymeleaf-layout-dialect") }
Note | |
---|---|
The version of the |
The dependency management plugin will only supply a version where one is not specified. To use a version of an artifact that differs from the one that the plugin would provide, simply specify the version when you declare the dependency as you usually would. For example:
dependencies {
compile("org.thymeleaf:thymeleaf-spring4:2.1.1.RELEASE")
}
To learn more about the capabilities of the Dependency Management Plugin, please refer to its documentation.
Once the spring-boot
plugin has been applied to your project it will automatically
attempt to rewrite archives to make them executable using the bootRepackage
task. You
should configure your project to build a jar or war (as appropriate) in the usual way.
The main class that you want to launch can either be specified using a configuration
option, or by adding a Main-Class
attribute to the manifest. If you don’t specify a
main class the plugin will search for a class with a
public static void main(String[] args)
method.
To build and run a project artifact, you can type the following:
$ gradle build $ java -jar build/libs/mymodule-0.0.1-SNAPSHOT.jar
To build a war file that is both executable and deployable into an external container, you need to mark the embedded container dependencies as belonging to a configuration named “providedRuntime”, e.g:
... apply plugin: 'war' war { baseName = 'myapp' version = '0.5.0' } repositories { jcenter() maven { url "http://repo.spring.io/libs-snapshot" } } configurations { providedRuntime } dependencies { compile("org.springframework.boot:spring-boot-starter-web") providedRuntime("org.springframework.boot:spring-boot-starter-tomcat") ... }
Tip | |
---|---|
See the “Section 77.1, “Create a deployable war file”” section for more details on how to create a deployable war file. |
To run a project in place without building a jar first you can use the “bootRun” task:
$ gradle bootRun
By default, running this way makes your static classpath resources (i.e. in
src/main/resources
by default) reloadable in the live application, which can be helpful
at development time. Making static classpath resources reloadable means that bootRun
does not use the output of the processResources
task, i.e., when invoked using
bootRun
, your application will use the resources in their unprocessed form.
You can disable the direct use of your static classpath resources. This will mean that
the resources are no longer reloadable but the output of the processResources
task will
be used. To do so, set addResources
on the bootRun
task to false
:
bootRun { addResources = false }
The gradle plugin automatically extends your build script DSL with a springBoot
element
for global configuration of the Boot plugin. Set the appropriate properties as you would
with any other Gradle extension (see below for a list of configuration options):
springBoot { backupSource = false }
The plugin adds a bootRepackage
task which you can also configure directly, e.g.:
bootRepackage {
mainClass = 'demo.Application'
}
The following configuration options are available:
Name | Description |
---|---|
| Boolean flag to switch the repackager off (sometimes useful if you want the other Boot features but not this one) |
| The main class that should be run. If not specified the |
| A file name segment (before the extension) to add to the archive, so that the original is preserved in its original location. Defaults to null in which case the archive is repackaged in place. The default is convenient for many purposes, but if you want to use the original jar as a dependency in another project, it’s best to use an extension to define the executable archive. |
| The name or value of the |
| The name of the custom configuration which is used to populate the nested lib directory (without specifying this you get all compile and runtime dependencies). |
| Boolean flag to indicate if jar files are fully executable on Unix like operating
systems. Defaults to |
| The embedded launch script to prepend to the front of the jar if it is fully executable. If not specified the 'Spring Boot' default script will be used. |
| Additional properties that to be expanded in the launch script. The default script
supports a |
Sometimes it may be more appropriate to not package default dependencies resolved from
compile
, runtime
and provided
scopes. If the created executable jar file
is intended to be run as it is, you need to have all dependencies nested inside it;
however, if the plan is to explode a jar file and run the main class manually, you may already
have some of the libraries available via CLASSPATH
. This is a situation where
you can repackage your jar with a different set of dependencies.
Using a custom
configuration will automatically disable dependency resolving from
compile
, runtime
and provided
scopes. Custom configuration can be either
defined globally (inside the springBoot
section) or per task.
task clientJar(type: Jar) { appendix = 'client' from sourceSets.main.output exclude('**/*Something*') } task clientBoot(type: BootRepackage, dependsOn: clientJar) { withJarTask = clientJar customConfiguration = "mycustomconfiguration" }
In above example, we created a new clientJar
Jar task to package a customized
file set from your compiled sources. Then we created a new clientBoot
BootRepackage task and instructed it to work with only clientJar
task and
mycustomconfiguration
.
configurations {
mycustomconfiguration.exclude group: 'log4j'
}
dependencies {
mycustomconfiguration configurations.runtime
}
The configuration that we are referring to in BootRepackage
is a normal
Gradle
configuration. In the above example we created a new configuration named
mycustomconfiguration
instructing it to derive from a runtime
and exclude the log4j
group. If the clientBoot
task is executed, the repackaged boot jar will have all
dependencies from runtime
but no log4j
jars.
The following configuration options are available:
Name | Description |
---|---|
| The main class that should be run by the executable archive. |
| The name of the provided configuration (defaults to |
| If the original source archive should be backed-up before being repackaged (defaults
to |
| The name of the custom configuration. |
| The type of archive, corresponding to how the dependencies are laid out inside (defaults to a guess based on the archive type). |
| A list of dependencies (in the form “groupId:artifactId” that must be unpacked from fat jars in order to run. Items are still packaged into the fat jar, but they will be automatically unpacked when it runs. |
When spring-boot
is applied to your Gradle project a default task named bootRepackage
is created automatically. The bootRepackage
task depends on Gradle assemble
task, and
when executed, it tries to find all jar artifacts whose qualifier is empty (i.e. tests and
sources jars are automatically skipped).
Due to the fact that bootRepackage
finds 'all' created jar artifacts, the order of
Gradle task execution is important. Most projects only create a single jar file, so
usually this is not an issue; however, if you are planning to create a more complex
project setup, with custom Jar
and BootRepackage
tasks, there are few tweaks to
consider.
If you are 'just' creating custom jar files from your project you can simply disable
default jar
and bootRepackage
tasks:
jar.enabled = false bootRepackage.enabled = false
Another option is to instruct the default bootRepackage
task to only work with a
default jar
task.
bootRepackage.withJarTask = jar
If you have a default project setup where the main jar file is created and repackaged,
'and' you still want to create additional custom jars, you can combine your custom
repackage tasks together and use dependsOn
so that the bootJars
task will run after
the default bootRepackage
task is executed:
task bootJars bootJars.dependsOn = [clientBoot1,clientBoot2,clientBoot3] build.dependsOn(bootJars)
All the above tweaks are usually used to avoid situations where an already created boot jar is repackaged again. Repackaging an existing boot jar will not break anything, but you may find that it includes unnecessary dependencies.
If you are declaring
dependencies without versions and you want to publish artifacts to a Maven repository
you will need to configure the Maven publication with details of Spring Boot’s
dependency management. This can be achieved by configuring it to publish poms that
inherit from spring-boot-starter-parent
or that import dependency management from
spring-boot-dependencies
. The exact details of this configuration depend on how you’re
using Gradle and how you’re trying to publish the artifacts.
The following is an example of configuring Gradle to generate a pom that inherits
from spring-boot-starter-parent
. Please refer to the
Gradle User Guide for
further information.
uploadArchives { repositories { mavenDeployer { pom { project { parent { groupId "org.springframework.boot" artifactId "spring-boot-starter-parent" version "1.3.0.M2" } } } } } }
The following is an example of configuring Gradle to generate a pom that imports
the dependency management provided by spring-boot-dependencies
. Please refer to the
Gradle User Guide for
further information.
uploadArchives { repositories { mavenDeployer { pom { project { dependencyManagement { dependencies { dependency { groupId "org.springframework.boot" artifactId "spring-boot-dependencies" version "1.3.0.M2" type "pom" scope "import" } } } } } } } }
The Spring Boot AntLib module provides basic Spring Boot support for Apache Ant. You can
use the module to create executable jars. To use the module you need to declare an
additional spring-boot
namespace in your build.xml
:
<project xmlns:ivy="antlib:org.apache.ivy.ant" xmlns:spring-boot="antlib:org.springframework.boot.ant" name="myapp" default="build"> ... </project>
You’ll need to remember to start Ant using the -lib
option, for example:
$ ant -lib <folder containing spring-boot-antlib-1.3.0.M2.jar>
Tip | |
---|---|
The “Using Spring Boot” section includes a more complete example of
using Apache Ant with |
Once the spring-boot-antlib
namespace has been declared, the following additional
tasks are available.
The exejar
task can be used to creates a Spring Boot executable jar. The following
attributes are supported by the task:
Attribute | Description | Required |
---|---|---|
| The destination jar file to create | Yes |
| The root directory of Java classfiles | Yes |
| The main application class to run | No (default is first class found declaring a |
The following nested elements can be used with the task:
Element | Description |
---|---|
| One or more Resource Collections describing a set of Resources that should be added to the content of the created jar file. |
| One or more Resource Collections that should be added to the set of jar libraries that make up the runtime dependency classpath of the application. |
Specify start-class.
<spring-boot:exejar destfile="target/my-application.jar" classes="target/classes" start-class="com.foo.MyApplication"> <resources> <fileset dir="src/main/resources" /> </resources> <lib> <fileset dir="lib" /> </lib> </spring-boot:exejar>
Detect start-class.
<exejar destfile="target/my-application.jar" classes="target/classes"> <lib> <fileset dir="lib" /> </lib> </exejar>
The findmainclass
task is used internally by exejar
to locate a class declaring a
main
. You can also use this task directly in your build if needed. The following
attributes are supported
Attribute | Description | Required |
---|---|---|
| The root directory of Java classfiles | Yes (unless |
| Can be used to short-circuit the | No |
| The Ant property that should be set with the result | No (result will be logged if unspecified) |
If you want to use a build tool other than Maven, Gradle or Ant, you will likely need to develop your own plugin. Executable jars need to follow a specific format and certain entries need to be written in an uncompressed form (see the executable jar format section in the appendix for details).
The Spring Boot Maven and Gradle plugins both make use of spring-boot-loader-tools
to
actually generate jars. You are also free to use this library directly yourself if you
need to.
To repackage an existing archive so that it becomes a self-contained executable archive
use org.springframework.boot.loader.tools.Repackager
. The Repackager
class takes a
single constructor argument that refers to an existing jar or war archive. Use one of the
two available repackage()
methods to either replace the original file or write to a new
destination. Various settings can also be configured on the repackager before it is
run.
When repackaging an archive you can include references to dependency files using the
org.springframework.boot.loader.tools.Libraries
interface. We don’t provide any
concrete implementations of Libraries
here as they are usually build system specific.
If your archive already includes libraries you can use Libraries.NONE
.
If you don’t use Repackager.setMainClass()
to specify a main class, the repackager will
use ASM to read class files and attempt to find a suitable class
with a public static void main(String[] args)
method. An exception is thrown if more
than one candidate is found.
Here is a typical example repackage:
Repackager repackager = new Repackager(sourceJarFile); repackager.setBackupSource(false); repackager.repackage(new Libraries() { @Override public void doWithLibraries(LibraryCallback callback) throws IOException { // Build system specific implementation, callback for each dependency // callback.library(new Library(nestedFile, LibraryScope.COMPILE)); } });
If you’re interested in how the build tool plugins work you can
look at the spring-boot-tools
module on GitHub. More
technical details of the executable
jar format are covered in the appendix.
If you have specific build-related questions you can check out the “how-to” guides.
This section provides answers to some common ‘how do I do that…’ type of questions that often arise when using Spring Boot. This is by no means an exhaustive list, but it does cover quite a lot.
If you are having a specific problem that we don’t cover here, you might want to check out
stackoverflow.com to see if someone has
already provided an answer; this is also a great place to ask new questions (please use
the spring-boot
tag).
We’re also more than happy to extend this section; If you want to add a ‘how-to’ you can send us a pull request.
The Spring Boot auto-configuration tries its best to ‘do the right thing’, but sometimes things fail and it can be hard to tell why.
There is a really useful ConditionEvaluationReport
available in any Spring Boot
ApplicationContext
. You will see it if you enable DEBUG
logging output. If you use
the spring-boot-actuator
there is also an autoconfig
endpoint that renders the report
in JSON. Use that to debug the application and see what features have been added (and
which not) by Spring Boot at runtime.
Many more questions can be answered by looking at the source code and the javadoc. Some rules of thumb:
*AutoConfiguration
and read their sources, in particular the
@Conditional*
annotations to find out what features they enable and when. Add
--debug
to the command line or a System property -Ddebug
to get a log on the
console of all the autoconfiguration decisions that were made in your app. In a running
Actuator app look at the autoconfig
endpoint (‘/autoconfig’ or the JMX equivalent) for
the same information.@ConfigurationProperties
(e.g.
ServerProperties
)
and read from there the available external configuration options. The
@ConfigurationProperties
has a name
attribute which acts as a prefix to external
properties, thus ServerProperties
has prefix="server"
and its configuration properties
are server.port
, server.address
etc. In a running Actuator app look at the
configprops
endpoint.RelaxedEnvironment
to pull configuration values explicitly out of the
Environment
. It often is used with a prefix.@Value
annotations that bind directly to the Environment
. This is less
flexible than the RelaxedEnvironment
approach, but does allow some relaxed binding,
specifically for OS environment variables (so CAPITALS_AND_UNDERSCORES
are synonyms
for period.separated
).@ConditionalOnExpression
annotations that switch features on and off in
response to SpEL expressions, normally evaluated with place-holders resolved from the
Environment
.A SpringApplication
has ApplicationListeners
and ApplicationContextInitializers
that
are used to apply customizations to the context or environment. Spring Boot loads a number
of such customizations for use internally from META-INF/spring.factories
. There is more
than one way to register additional ones:
addListeners
and addInitializers
methods on SpringApplication
before you run it.context.initializer.classes
or
context.listener.classes
.META-INF/spring.factories
and packaging
a jar file that the applications all use as a library.The SpringApplication
sends some special ApplicationEvents
to the listeners (even
some before the context is created), and then registers the listeners for events published
by the ApplicationContext
as well. See
Section 23.4, “Application events and listeners” in the
‘Spring Boot features’ section for a complete list.
You can use the ApplicationBuilder
class to create parent/child ApplicationContext
hierarchies. See Section 23.3, “Fluent builder API”
in the ‘Spring Boot features’ section for more information.
Not all Spring applications have to be web applications (or web services). If you want to
execute some code in a main
method, but also bootstrap a Spring application to set up
the infrastructure to use, then it’s easy with the SpringApplication
features of Spring
Boot. A SpringApplication
changes its ApplicationContext
class depending on whether it
thinks it needs a web application or not. The first thing you can do to help it is to just
leave the servlet API dependencies off the classpath. If you can’t do that (e.g. you are
running 2 applications from the same code base) then you can explicitly call
SpringApplication.setWebEnvironment(false)
, or set the applicationContextClass
property (through the Java API or with external properties).
Application code that you want to run as your business logic can be implemented as a
CommandLineRunner
and dropped into the context as a @Bean
definition.
A SpringApplication
has bean properties (mainly setters) so you can use its Java API as
you create the application to modify its behavior. Or you can externalize the
configuration using properties in spring.main.*
. E.g. in application.properties
you
might have.
spring.main.web_environment=false spring.main.show_banner=false
and then the Spring Boot banner will not be printed on startup, and the application will not be a web application.
Note | |
---|---|
The example above also demonstrates how flexible binding allows the use of
underscores ( |
Properties defined in external configuration overrides the values specified via the Java
API with the notable exception of the sources used to create the ApplicationContext
. Let’s
consider this application
new SpringApplicationBuilder() .showBanner(false) .sources(demo.MyApp.class) .run(args);
used with the following configuration:
spring.main.sources=com.acme.Config,com.acme.ExtraConfig spring.main.show-banner=true
The actual application will now show the banner (as overridden by configuration) and use
three sources for the ApplicationContext
(in that order): demo.MyApp
, com.acme.Config
,
com.acme.ExtraConfig
.
By default properties from different sources are added to the Spring Environment
in a
defined order (see Chapter 24, Externalized Configuration in
the ‘Spring Boot features’ section for the exact order).
A nice way to augment and modify this is to add @PropertySource
annotations to your
application sources. Classes passed to the SpringApplication
static convenience
methods, and those added using setSources()
are inspected to see if they have
@PropertySources
, and if they do, those properties are added to the Environment
early
enough to be used in all phases of the ApplicationContext
lifecycle. Properties added
in this way have precedence over any added using the default locations, but have lower
priority than system properties, environment variables or the command line.
You can also provide System properties (or environment variables) to change the behavior:
spring.config.name
(SPRING_CONFIG_NAME
), defaults to application
as the root of
the file name.spring.config.location
(SPRING_CONFIG_LOCATION
) is the file to load (e.g. a classpath
resource or a URL). A separate Environment
property source is set up for this document
and it can be overridden by system properties, environment variables or the
command line.No matter what you set in the environment, Spring Boot will always load
application.properties
as described above. If YAML is used then files with the ‘.yml’
extension are also added to the list by default.
Spring Boot logs the configuration files that are loaded at DEBUG
level and the
candidates it has not found at TRACE
level.
See ConfigFileApplicationListener
for more detail.
Some people like to use (for example) --port=9000
instead of --server.port=9000
to
set configuration properties on the command line. You can easily enable this by using
placeholders in application.properties
, e.g.
server.port=${port:8080}
Tip | |
---|---|
If you are inheriting from the |
Note | |
---|---|
In this specific case the port binding will work in a PaaS environment like Heroku
and Cloud Foundry, since in those two platforms the |
YAML is a superset of JSON and as such is a very convenient syntax for storing external properties in a hierarchical format. E.g.
spring: application: name: cruncher datasource: driverClassName: com.mysql.jdbc.Driver url: jdbc:mysql://localhost/test server: port: 9000
Create a file called application.yml
and stick it in the root of your classpath, and
also add snakeyaml
to your dependencies (Maven coordinates org.yaml:snakeyaml
, already
included if you use the spring-boot-starter
). A YAML file is parsed to a Java
Map<String,Object>
(like a JSON object), and Spring Boot flattens the map so that it
is 1-level deep and has period-separated keys, a lot like people are used to with
Properties
files in Java.
The example YAML above corresponds to an application.properties
file
spring.application.name=cruncher spring.datasource.driverClassName=com.mysql.jdbc.Driver spring.datasource.url=jdbc:mysql://localhost/test server.port=9000
See Section 24.6, “Using YAML instead of Properties” in the ‘Spring Boot features’ section for more information about YAML.
The Spring Environment
has an API for this, but normally you would set a System profile
(spring.profiles.active
) or an OS environment variable (SPRING_PROFILES_ACTIVE
). E.g.
launch your application with a -D
argument (remember to put it before the main class
or jar archive):
$ java -jar -Dspring.profiles.active=production demo-0.0.1-SNAPSHOT.jar
In Spring Boot you can also set the active profile in application.properties
, e.g.
spring.profiles.active=production
A value set this way is replaced by the System property or environment variable setting,
but not by the SpringApplicationBuilder.profiles()
method. Thus the latter Java API can
be used to augment the profiles without changing the defaults.
See Chapter 25, Profiles in the ‘Spring Boot features’ section for more information.
A YAML file is actually a sequence of documents separated by ---
lines, and each
document is parsed separately to a flattened map.
If a YAML document contains a spring.profiles
key, then the profiles value
(comma-separated list of profiles) is fed into the Spring
Environment.acceptsProfiles()
and if any of those profiles is active that document is
included in the final merge (otherwise not).
Example:
server: port: 9000 --- spring: profiles: development server: port: 9001 --- spring: profiles: production server: port: 0
In this example the default port is 9000, but if the Spring profile ‘development’ is active then the port is 9001, and if ‘production’ is active then it is 0.
The YAML documents are merged in the order they are encountered (so later values override earlier ones).
To do the same thing with properties files you can use application-${profile}.properties
to specify profile-specific values.
Spring Boot binds external properties from application.properties
(or .yml
) (and
other places) into an application at runtime. There is not (and technically cannot be)
an exhaustive list of all supported properties in a single location because contributions
can come from additional jar files on your classpath.
A running application with the Actuator features has a configprops
endpoint that shows
all the bound and bindable properties available through @ConfigurationProperties
.
The appendix includes an application.properties
example with a list of the most common properties supported by
Spring Boot. The definitive list comes from searching the source code for
@ConfigurationProperties
and @Value
annotations, as well as the occasional use of
RelaxedEnvironment
.
Servlet
, Filter
, ServletContextListener
and the other listeners supported by the
Servlet spec can be added to your application as @Bean
definitions. Be very careful that
they don’t cause eager initialization of too many other beans because they have to be
installed in the container very early in the application lifecycle (e.g. it’s not a good
idea to have them depend on your DataSource
or JPA configuration). You can work around
restrictions like that by initializing them lazily when first used instead of on
initialization.
In the case of Filters
and Servlets
you can also add mappings and init parameters by
adding a FilterRegistrationBean
or ServletRegistrationBean
instead of or as well as
the underlying component.
As described above any Servlet
or Filter
beans will be registered with the servlet container automatically. To disable
registration of a particular Filter
or Servlet
bean create a registration bean for it
and mark it as disabled. For example:
@Bean public FilterRegistrationBean registration(MyFilter filter) { FilterRegistrationBean registration = new FilterRegistrationBean(filter); registration.setEnabled(false); return registration; }
In a standalone application the main HTTP port defaults to 8080
, but can be set with
server.port
(e.g. in application.properties
or as a System property). Thanks to
relaxed binding of Environment
values you can also use SERVER_PORT
(e.g. as an OS
environment variable).
To switch off the HTTP endpoints completely, but still create a WebApplicationContext
,
use server.port=-1
(this is sometimes useful for testing).
For more details look at Section 27.3.3, “Customizing embedded servlet containers”
in the ‘Spring Boot features’ section, or the
ServerProperties
source
code.
To scan for a free port (using OS natives to prevent clashes) use server.port=0
.
Tip | |
---|---|
You can know what port got allocated at runtime by looking at the |
You can access the port the server is running on from log output or from the
EmbeddedWebApplicationContext
via its EmbeddedServletContainer
. The best way to get
that and be sure that it has initialized is to add a @Bean
of type
ApplicationListener<EmbeddedServletContainerInitializedEvent>
and pull the container
out of the event when it is published.
A useful practice for use with @WebIntegrationTests
is to set server.port=0
and then inject the actual (‘local’) port as a @Value
. For example:
@RunWith(SpringJUnit4ClassRunner.class) @SpringApplicationConfiguration(classes = SampleDataJpaApplication.class) @WebIntegrationTest("server.port:0") public class CityRepositoryIntegrationTests { @Autowired EmbeddedWebApplicationContext server; @Value("${local.server.port}") int port; // ... }
SSL can be configured declaratively by setting the various server.ssl.*
properties,
typically in application.properties
or application.yml
. For example:
server.port=8443 server.ssl.key-store=classpath:keystore.jks server.ssl.key-store-password=secret server.ssl.key-password=another-secret
See Ssl
for details of all of the
supported properties.
Note | |
---|---|
Tomcat requires the key store (and trust store if you’re using one) to be directly accessible on the filesystem, i.e. it cannot be read from within a jar file. This limitation doesn’t apply to Jetty and Undertow. |
Using configuration like the example above means the application will no longer support
plain HTTP connector at port 8080. Spring Boot doesn’t support the configuration of both
an HTTP connector and an HTTPS connector via application.properties
. If you want to
have both then you’ll need to configure one of them programmatically. It’s recommended
to use application.properties
to configure HTTPS as the HTTP connector is the easier of
the two to configure programmatically. See the
spring-boot-sample-tomcat-multi-connectors
sample project for an example.
Generally you can follow the advice from
Section 66.7, “Discover built-in options for external properties” about
@ConfigurationProperties
(ServerProperties
is the main one here), but also look at
EmbeddedServletContainerCustomizer
and various Tomcat-specific *Customizers
that you
can add in one of those. The Tomcat APIs are quite rich so once you have access to the
TomcatEmbeddedServletContainerFactory
you can modify it in a number of ways. Or the
nuclear option is to add your own TomcatEmbeddedServletContainerFactory
.
Add a org.apache.catalina.connector.Connector
to the
TomcatEmbeddedServletContainerFactory
which can allow multiple connectors, e.g. HTTP and
HTTPS connector:
@Bean public EmbeddedServletContainerFactory servletContainer() { TomcatEmbeddedServletContainerFactory tomcat = new TomcatEmbeddedServletContainerFactory(); tomcat.addAdditionalTomcatConnectors(createSslConnector()); return tomcat; } private Connector createSslConnector() { Connector connector = new Connector("org.apache.coyote.http11.Http11NioProtocol"); Http11NioProtocol protocol = (Http11NioProtocol) connector.getProtocolHandler(); try { File keystore = new ClassPathResource("keystore").getFile(); File truststore = new ClassPathResource("keystore").getFile(); connector.setScheme("https"); connector.setSecure(true); connector.setPort(8443); protocol.setSSLEnabled(true); protocol.setKeystoreFile(keystore.getAbsolutePath()); protocol.setKeystorePass("changeit"); protocol.setTruststoreFile(truststore.getAbsolutePath()); protocol.setTruststorePass("changeit"); protocol.setKeyAlias("apitester"); return connector; } catch (IOException ex) { throw new IllegalStateException("can't access keystore: [" + "keystore" + "] or truststore: [" + "keystore" + "]", ex); } }
Spring Boot will automatically configure Tomcat’s RemoteIpValve
if you enable it. This
allows you to transparently use the standard x-forwarded-for
and x-forwarded-proto
headers that most front-end proxy servers add. The valve is switched on by setting one or
both of these properties to something non-empty (these are the conventional values used by
most proxies, and if you only set one the other will be set automatically):
server.tomcat.remote_ip_header=x-forwarded-for server.tomcat.protocol_header=x-forwarded-proto
If your proxy uses different headers you can customize the valve’s configuration by adding
some entries to application.properties
, e.g.
server.tomcat.remote_ip_header=x-your-remote-ip-header server.tomcat.protocol_header=x-your-protocol-header
The valve is also configured with a default regular expression that matches internal
proxies that are to be trusted. By default, IP addresses in 10/8, 192.168/16, 169.254/16
and 127/8 are trusted. You can customize the valve’s configuration by adding an entry
to application.properties
, e.g.
server.tomcat.internal_proxies=192\\.168\\.\\d{1,3}\\.\\d{1,3}
Note | |
---|---|
The double backslashes are only required when you’re using a properties file for
configuration. If you are using YAML, single backslashes are sufficient and a value
that’s equivalent to the one shown above would be |
Alternatively, you can take complete control of the configuration of the RemoteIpValve
by configuring and adding it in a TomcatEmbeddedServletContainerFactory
bean.
The Spring Boot starters (spring-boot-starter-web
in particular) use Tomcat as an
embedded container by default. You need to exclude those dependencies and include the
Jetty one instead. Spring Boot provides Tomcat and Jetty dependencies bundled together
as separate starters to help make this process as easy as possible.
Example in Maven:
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> <exclusions> <exclusion> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-tomcat</artifactId> </exclusion> </exclusions> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-jetty</artifactId> </dependency>
Example in Gradle:
configurations { compile.exclude module: "spring-boot-starter-tomcat" } dependencies { compile("org.springframework.boot:spring-boot-starter-web:1.3.0.M2") compile("org.springframework.boot:spring-boot-starter-jetty:1.3.0.M2") // ... }
Generally you can follow the advice from
Section 66.7, “Discover built-in options for external properties” about
@ConfigurationProperties
(ServerProperties
is the main one here), but also look at
EmbeddedServletContainerCustomizer
. The Jetty APIs are quite rich so once you have
access to the JettyEmbeddedServletContainerFactory
you can modify it in a number
of ways. Or the nuclear option is to add your own JettyEmbeddedServletContainerFactory
.
Using Undertow instead of Tomcat is very similar to using Jetty instead of Tomcat. You need to exclude the Tomcat dependencies and include the Undertow starter instead.
Example in Maven:
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> <exclusions> <exclusion> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-tomcat</artifactId> </exclusion> </exclusions> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-undertow</artifactId> </dependency>
Example in Gradle:
configurations { compile.exclude module: "spring-boot-starter-tomcat" } dependencies { compile("org.springframework.boot:spring-boot-starter-web:1.3.0.M2") compile("org.springframework.boot:spring-boot-starter-undertow:1.3.0.M2") // ... }
Generally you can follow the advice from
Section 66.7, “Discover built-in options for external properties” about
@ConfigurationProperties
(ServerProperties
and ServerProperties.Undertow
are the
main ones here), but also look at
EmbeddedServletContainerCustomizer
. Once you have access to the
UndertowEmbeddedServletContainerFactory
you can use an UndertowBuilderCustomizer
to
modify Undertow’s configuration to meet your needs. Or the nuclear option is to add your
own UndertowEmbeddedServletContainerFactory
.
Add an UndertowBuilderCustomizer
to the UndertowEmbeddedServletContainerFactory
and
add a listener to the Builder
:
@Bean public UndertowEmbeddedServletContainerFactory embeddedServletContainerFactory() { UndertowEmbeddedServletContainerFactory factory = new UndertowEmbeddedServletContainerFactory(); factory.addBuilderCustomizers(new UndertowBuilderCustomizer() { @Override public void customize(Builder builder) { builder.addHttpListener(8080, "0.0.0.0"); } }); return factory; }
Tomcat 7 works with Spring Boot, but the default is to use Tomcat 8. If you cannot use Tomcat 8 (for example, because you are using Java 1.6) you will need to change your classpath to reference Tomcat 7 .
If you are using the starter poms and parent you can just change the Tomcat version property, e.g. for a simple webapp or service:
<properties> <tomcat.version>7.0.59</tomcat.version> </properties> <dependencies> ... <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> ... </dependencies>
Jetty 8 works with Spring Boot, but the default is to use Jetty 9. If you cannot use Jetty 9 (for example, because you are using Java 1.6) you will need to change your classpath to reference Jetty 8. You will also need to exclude Jetty’s WebSocket-related dependencies.
If you are using the starter poms and parent you can just add the Jetty starter with the required WebSocket exclusion and change the version properties, e.g. for a simple webapp or service:
<properties> <jetty.version>8.1.15.v20140411</jetty.version> <jetty-jsp.version>2.2.0.v201112011158</jetty-jsp.version> </properties> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> <exclusions> <exclusion> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-tomcat</artifactId> </exclusion> </exclusions> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-jetty</artifactId> <exclusions> <exclusion> <groupId>org.eclipse.jetty.websocket</groupId> <artifactId>*</artifactId> </exclusion> </exclusions> </dependency> </dependencies>
You can set the jetty.version
property and exclude the WebSocket dependency, e.g. for a
simple webapp or service:
ext['jetty.version'] = '8.1.15.v20140411' dependencies { compile ('org.springframework.boot:spring-boot-starter-web') { exclude group: 'org.springframework.boot', module: 'spring-boot-starter-tomcat' } compile ('org.springframework.boot:spring-boot-starter-jetty') { exclude group: 'org.eclipse.jetty.websocket' } }
If you want to use @ServerEndpoint
in a Spring Boot application that used an embedded
container, you must declare a single ServerEndpointExporter
@Bean
:
@Bean public ServerEndpointExporter serverEndpointExporter() { return new ServerEndpointExporter(); }
This bean will register any @ServerEndpoint
annotated beans with the underlying
WebSocket container. When deployed to a standalone servlet container this role is
performed by a servlet container initializer and the ServerEndpointExporter
bean is
not required.
HTTP response compression is supported by Jetty, Tomcat, and Undertow. It can be enabled
via application.properties
:
server.compression.enabled=true
By default, responses must be at least 2048 bytes in length for compression to be
performed. This can be configured using the server.compression.min-response-size
property.
By default, responses will only be compressed if their content type is one of the following:
text/html
text/xml
text/plain
text/css
This can be configured using the server.compression.mime-types
property.
Any Spring @RestController
in a Spring Boot application should render JSON response by
default as long as Jackson2 is on the classpath. For example:
@RestController public class MyController { @RequestMapping("/thing") public MyThing thing() { return new MyThing(); } }
As long as MyThing
can be serialized by Jackson2 (e.g. a normal POJO or Groovy object)
then localhost:8080/thing
will serve a JSON representation of it by default.
Sometimes in a browser you might see XML responses because browsers tend to send accept
headers that prefer XML.
If you have the Jackson XML extension (jackson-dataformat-xml
) on the classpath, it will
be used to render XML responses and the very same example as we used for JSON would work.
To use it, add the following dependency to your project:
<dependency> <groupId>com.fasterxml.jackson.dataformat</groupId> <artifactId>jackson-dataformat-xml</artifactId> </dependency>
You may also want to add a dependency on Woodstox. It’s faster than the default Stax implementation provided by the JDK and also adds pretty print support and improved namespace handling:
<dependency> <groupId>org.codehaus.woodstox</groupId> <artifactId>woodstox-core-asl</artifactId> </dependency>
If Jackson’s XML extension is not available, JAXB (provided by default in the JDK) will
be used, with the additional requirement to have MyThing
annotated as
@XmlRootElement
:
@XmlRootElement public class MyThing { private String name; // .. getters and setters }
To get the server to render XML instead of JSON you might have to send an
Accept: text/xml
header (or use a browser).
Spring MVC (client and server side) uses HttpMessageConverters
to negotiate content
conversion in an HTTP exchange. If Jackson is on the classpath you already get the
default converter(s) provided by Jackson2ObjectMapperBuilder
.
The ObjectMapper
(or XmlMapper
for Jackson XML converter) instance created by default
have the following customized properties:
MapperFeature.DEFAULT_VIEW_INCLUSION
is disabledDeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES
is disabledSpring Boot has also some features to make it easier to customize this behavior.
You can configure the ObjectMapper
and XmlMapper
instances using the environment.
Jackson provides an extensive suite of simple on/off features that can be used to
configure various aspects of its processing. These features are described in six enums in
Jackson which map onto properties in the environment:
Jackson enum | Environment property |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
For example, to enable pretty print, set spring.jackson.serialization.indent_output=true
.
Note that, thanks to the use of relaxed binding, the case of indent_output
doesn’t have to match the case of the
corresponding enum constant which is INDENT_OUTPUT
.
If you want to replace the default ObjectMapper
completely, define a @Bean
of that
type and mark it as @Primary
.
Defining a @Bean
of type Jackson2ObjectMapperBuilder
will allow you to customize both
default ObjectMapper
and XmlMapper
(used in MappingJackson2HttpMessageConverter
and
MappingJackson2XmlHttpMessageConverter
respectively).
Another way to customize Jackson is to add beans of type
com.fasterxml.jackson.databind.Module
to your context. They will be registered with every
bean of type ObjectMapper
, providing a global mechanism for contributing custom modules
when you add new features to your application.
Finally, if you provide any @Beans
of type MappingJackson2HttpMessageConverter
then
they will replace the default value in the MVC configuration. Also, a convenience bean is
provided of type HttpMessageConverters
(always available if you use the default MVC
configuration) which has some useful methods to access the default and user-enhanced
message converters.
See also the Section 68.4, “Customize the @ResponseBody rendering” section and the
WebMvcAutoConfiguration
source code for more details.
Spring uses HttpMessageConverters
to render @ResponseBody
(or responses from
@RestController
). You can contribute additional converters by simply adding beans of
that type in a Spring Boot context. If a bean you add is of a type that would have been
included by default anyway (like MappingJackson2HttpMessageConverter
for JSON
conversions) then it will replace the default value. A convenience bean is provided of
type HttpMessageConverters
(always available if you use the default MVC configuration)
which has some useful methods to access the default and user-enhanced message converters
(useful, for example if you want to manually inject them into a custom RestTemplate
).
As in normal MVC usage, any WebMvcConfigurerAdapter
beans that you provide can also
contribute converters by overriding the configureMessageConverters
method, but unlike
with normal MVC, you can supply only additional converters that you need (because Spring
Boot uses the same mechanism to contribute its defaults). Finally, if you opt-out of the
Spring Boot default MVC configuration by providing your own @EnableWebMvc
configuration,
then you can take control completely and do everything manually using
getMessageConverters
from WebMvcConfigurationSupport
.
See the WebMvcAutoConfiguration
source code for more details.
Spring Boot embraces the Servlet 3 javax.servlet.http.Part
API to support uploading
files. By default Spring Boot configures Spring MVC with a maximum file of 1Mb per
file and a maximum of 10Mb of file data in a single request. You may override these
values, as well as the location to which intermediate data is stored (e.g., to the /tmp
directory) and the threshold past which data is flushed to disk by using the properties
exposed in the MultipartProperties
class. If you want to specify that files be
unlimited, for example, set the multipart.maxFileSize
property to -1
.
The multipart support is helpful when you want to receive multipart encoded file data as
a @RequestParam
-annotated parameter of type MultipartFile
in a Spring MVC controller
handler method.
See the MultipartAutoConfiguration
source for more details.
Spring Boot wants to serve all content from the root of your application /
down. If you
would rather map your own servlet to that URL you can do it, but of course you may lose
some of the other Boot MVC features. To add your own servlet and map it to the root
resource just declare a @Bean
of type Servlet
and give it the special bean name
dispatcherServlet
(You can also create a bean of a different type with that name if
you want to switch it off and not replace it).
The easiest way to take complete control over MVC configuration is to provide your own
@Configuration
with the @EnableWebMvc
annotation. This will leave all MVC
configuration in your hands.
A ViewResolver
is a core component of Spring MVC, translating view names in
@Controller
to actual View
implementations. Note that ViewResolvers
are mainly
used in UI applications, rather than REST-style services (a View
is not used to render
a @ResponseBody
). There are many implementations of ViewResolver
to choose from, and
Spring on its own is not opinionated about which ones you should use. Spring Boot, on the
other hand, installs one or two for you depending on what it finds on the classpath and
in the application context. The DispatcherServlet
uses all the resolvers it finds in
the application context, trying each one in turn until it gets a result, so if you are
adding your own you have to be aware of the order and in which position your resolver is
added.
WebMvcAutoConfiguration
adds the following ViewResolvers
to your context:
InternalResourceViewResolver
with bean id ‘defaultViewResolver’. This one locates
physical resources that can be rendered using the DefaultServlet
(e.g. static
resources and JSP pages if you are using those). It applies a prefix and a suffix to the
view name and then looks for a physical resource with that path in the servlet context
(defaults are both empty, but accessible for external configuration via
spring.mvc.view.prefix
and spring.mvc.view.suffix
). It can be overridden by providing a
bean of the same type.BeanNameViewResolver
with id ‘beanNameViewResolver’. This is a useful member of the
view resolver chain and will pick up any beans with the same name as the View
being
resolved. It shouldn’t be necessary to override or replace it.ContentNegotiatingViewResolver
with id ‘viewResolver’ is only added if there are
actually beans of type View
present. This is a ‘master’ resolver, delegating to all
the others and attempting to find a match to the ‘Accept’ HTTP header sent by the
client. There is a useful
blog about ContentNegotiatingViewResolver
that you might like to study to learn more, and also look at the source code for detail.
You can switch off the auto-configured
ContentNegotiatingViewResolver
by defining a bean named ‘viewResolver’.ThymeleafViewResolver
with id
‘thymeleafViewResolver’. It looks for resources by surrounding the view name with a
prefix and suffix (externalized to spring.thymeleaf.prefix
and
spring.thymeleaf.suffix
, defaults ‘classpath:/templates/’ and ‘.html’
respectively). It can be overridden by providing a bean of the same name.FreeMarkerViewResolver
with id
‘freeMarkerViewResolver’. It looks for resources in a loader path (externalized to
spring.freemarker.templateLoaderPath
, default ‘classpath:/templates/’) by
surrounding the view name with a prefix and suffix (externalized to spring.freemarker.prefix
and spring.freemarker.suffix
, with empty and ‘.ftl’ defaults respectively). It can
be overridden by providing a bean of the same name.GroovyMarkupViewResolver
with id ‘groovyMarkupViewResolver’. It
looks for resources in a loader path by surrounding the view name with a prefix and
suffix (externalized to spring.groovy.template.prefix
and
spring.groovy.template.suffix
, defaults ‘classpath:/templates/’ and ‘.tpl’
respectively). It can be overriden by providing a bean of the same name.VelocityViewResolver
with id ‘velocityViewResolver’.
It looks for resources in a loader path (externalized to spring.velocity.resourceLoaderPath
,
default ‘classpath:/templates/’) by surrounding the view name with a prefix and suffix
(externalized to spring.velocity.prefix
and spring.velocity.suffix
, with empty and ‘.vm’
defaults respectively). It can be overridden by providing a bean of the same name.Check out WebMvcAutoConfiguration
,
ThymeleafAutoConfiguration
,
FreeMarkerAutoConfiguration
,
GroovyTemplateAutoConfiguration
and
VelocityAutoConfiguration
Spring Boot has no mandatory logging dependence, except for the commons-logging
API, of
which there are many implementations to choose from. To use Logback
you need to include it, and some bindings for commons-logging
on the classpath. The
simplest way to do that is through the starter poms which all depend on
spring-boot-starter-logging
. For a web application you only need
spring-boot-starter-web
since it depends transitively on the logging starter.
For example, using Maven:
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency>
Spring Boot has a LoggingSystem
abstraction that attempts to configure logging based on
the content of the classpath. If Logback is available it is the first choice.
If the only change you need to make to logging is to set the levels of various loggers
then you can do that in application.properties
using the "logging.level" prefix, e.g.
logging.level.org.springframework.web=DEBUG logging.level.org.hibernate=ERROR
You can also set the location of a file to log to (in addition to the console) using "logging.file".
To configure the more fine-grained settings of a logging system you need to use the native
configuration format supported by the LoggingSystem
in question. By default Spring Boot
picks up the native configuration from its default location for the system (e.g.
classpath:logback.xml
for Logback), but you can set the location of the config file
using the "logging.config" property.
If you put a logback-spring.xml
in the root of your classpath it will be picked up from
there. Spring Boot provides a default base configuration that you can include if you just
want to set levels, e.g.
<?xml version="1.0" encoding="UTF-8"?> <configuration> <include resource="org/springframework/boot/logging/logback/base.xml"/> <logger name="org.springframework.web" level="DEBUG"/> </configuration>
If you look at the default logback.xml
in the spring-boot jar you will see that it uses
some useful System properties which the LoggingSystem
takes care of creating for you.
These are:
${PID}
the current process ID.${LOG_FILE}
if logging.file
was set in Boot’s external configuration.${LOG_PATH}
if logging.path
was set (representing a directory for
log files to live in).Spring Boot also provides some nice ANSI colour terminal output on a console (but not in
a log file) using a custom Logback converter. See the default base.xml
configuration
for details.
If Groovy is on the classpath you should be able to configure Logback with
logback.groovy
as well (it will be given preference if present).
Spring Boot also supports either Log4j or
Log4j 2 for logging configuration, but only if one
of them is on the classpath. If you are using the starter poms for assembling
dependencies that means you have to exclude Logback and then include your chosen version
of Log4j instead. If you aren’t using the starter poms then you need to provide
commons-logging
(at least) in addition to your chosen version of Log4j.
The simplest path is probably through the starter poms, even though it requires some jiggling with excludes, .e.g. in Maven:
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter</artifactId> <exclusions> <exclusion> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-logging</artifactId> </exclusion> </exclusions> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-log4j</artifactId> </dependency>
To use Log4j 2, simply depend on spring-boot-starter-log4j2
rather than
spring-boot-starter-log4j
.
Note | |
---|---|
The use of one of the Log4j starters gathers together the dependencies for
common logging requirements (e.g. including having Tomcat use |
In addition to its default XML configuration format, Log4j 2 also supports YAML and JSON
configuration files. To configure Log4j 2 to use an alternative configuration file format
all you need to do is add an appropriate dependency to the classpath. To use YAML, add a
dependency on com.fasterxml.jackson.dataformat:jackson-dataformat-yaml
and Log4j 2 will
look for configuration files names log4j2.yaml
or log4j2.yml
. To use JSON, add a
dependency on com.fasterxml.jackson.core:jackson-databind
and Log4j 2 will look for
configuration files named log4j2.json
or log4j2.jsn
To override the default settings just define a @Bean
of your own of type DataSource
.
Spring Boot provides a utility builder class DataSourceBuilder
that can be used
to create one of the standard ones (if it is on the classpath), or you can just create
your own, and bind it to a set of Environment
properties as explained in
Section 24.7.1, “Third-party configuration”, e.g.
@Bean @ConfigurationProperties(prefix="datasource.mine") public DataSource dataSource() { return new FancyDataSource(); }
datasource.mine.jdbcUrl=jdbc:h2:mem:mydb datasource.mine.user=sa datasource.mine.poolSize=30
See Section 29.1, “Configure a DataSource” in the
‘Spring Boot features’ section and the
DataSourceAutoConfiguration
class for more details.
Creating more than one data source works the same as creating the first one. You might
want to mark one of them as @Primary
if you are using the default auto-configuration for
JDBC or JPA (then that one will be picked up by any @Autowired
injections).
@Bean @Primary @ConfigurationProperties(prefix="datasource.primary") public DataSource primaryDataSource() { return DataSourceBuilder.create().build(); } @Bean @ConfigurationProperties(prefix="datasource.secondary") public DataSource secondaryDataSource() { return DataSourceBuilder.create().build(); }
Spring Data can create implementations for you of @Repository
interfaces of various
flavors. Spring Boot will handle all of that for you as long as those @Repositories
are included in the same package (or a sub-package) of your @EnableAutoConfiguration
class.
For many applications all you will need is to put the right Spring Data dependencies on
your classpath (there is a spring-boot-starter-data-jpa
for JPA and a
spring-boot-starter-data-mongodb
for Mongodb), create some repository interfaces to handle your
@Entity
objects. Examples are in the JPA sample
or the Mongodb sample.
Spring Boot tries to guess the location of your @Repository
definitions, based on the
@EnableAutoConfiguration
it finds. To get more control, use the @EnableJpaRepositories
annotation (from Spring Data JPA).
Spring Boot tries to guess the location of your @Entity
definitions, based on the
@EnableAutoConfiguration
it finds. To get more control, you can use the @EntityScan
annotation, e.g.
@Configuration @EnableAutoConfiguration @EntityScan(basePackageClasses=City.class) public class Application { //... }
Spring Data JPA already provides some vendor-independent configuration options (e.g. for SQL logging) and Spring Boot exposes those, and a few more for hibernate as external configuration properties. The most common options to set are:
spring.jpa.hibernate.ddl-auto: create-drop spring.jpa.hibernate.naming_strategy: org.hibernate.cfg.ImprovedNamingStrategy spring.jpa.database: H2 spring.jpa.show-sql: true
(Because of relaxed data binding hyphens or underscores should work equally well as
property keys.) The ddl-auto
setting is a special case in that it has different
defaults depending on whether you are using an embedded database (create-drop
) or not
(none
). In addition all properties in spring.jpa.properties.*
are passed through as
normal JPA properties (with the prefix stripped) when the local EntityManagerFactory
is
created.
See HibernateJpaAutoConfiguration
and JpaBaseConfiguration
for more details.
To take full control of the configuration of the EntityManagerFactory
, you need to add
a @Bean
named ‘entityManagerFactory’. Spring Boot auto-configuration switches off its
entity manager based on the presence of a bean of that type.
Even if the default EntityManagerFactory
works fine, you will need to define a new one
because otherwise the presence of the second bean of that type will switch off the
default. To make it easy to do that you can use the convenient EntityManagerBuilder
provided by Spring Boot, or if you prefer you can just use the
LocalContainerEntityManagerFactoryBean
directly from Spring ORM.
Example:
// add two data sources configured as above @Bean public LocalContainerEntityManagerFactoryBean customerEntityManagerFactory( EntityManagerFactoryBuilder builder) { return builder .dataSource(customerDataSource()) .packages(Customer.class) .persistenceUnit("customers") .build(); } @Bean public LocalContainerEntityManagerFactoryBean orderEntityManagerFactory( EntityManagerFactoryBuilder builder) { return builder .dataSource(orderDataSource()) .packages(Order.class) .persistenceUnit("orders") .build(); }
The configuration above almost works on its own. To complete the picture you need to
configure TransactionManagers
for the two EntityManagers
as well. One of them could
be picked up by the default JpaTransactionManager
in Spring Boot if you mark it as
@Primary
. The other would have to be explicitly injected into a new instance. Or you
might be able to use a JTA transaction manager spanning both.
Spring doesn’t require the use of XML to configure the JPA provider, and Spring Boot
assumes you want to take advantage of that feature. If you prefer to use persistence.xml
then you need to define your own @Bean
of type LocalEntityManagerFactoryBean
(with
id ‘entityManagerFactory’, and set the persistence unit name there.
See
JpaBaseConfiguration
for the default settings.
Spring Data JPA and Spring Data Mongo can both create Repository
implementations for you
automatically. If they are both present on the classpath, you might have to do some extra
configuration to tell Spring Boot which one (or both) you want to create repositories for
you. The most explicit way to do that is to use the standard Spring Data
@Enable*Repositories
and tell it the location of your Repository
interfaces
(where ‘*’ is ‘Jpa’ or ‘Mongo’ or both).
There are also flags spring.data.*.repositories.enabled
that you can use to switch the
auto-configured repositories on and off in external configuration. This is useful for
instance in case you want to switch off the Mongo repositories and still use the
auto-configured MongoTemplate
.
The same obstacle and the same features exist for other auto-configured Spring Data repository types (Elasticsearch, Solr). Just change the names of the annotations and flags respectively.
Spring Data REST can expose the Repository
implementations as REST endpoints for you as
long as Spring MVC has been enabled for the application.
Spring Boot exposes as set of useful properties from the spring.data.rest
namespace that
customize the RepositoryRestConfiguration
.
If you need to provide additional customization, you can create a @Configuration
class
that extends SpringBootRepositoryRestMvcConfiguration
. This class supports the same
functionality as RepositoryRestMvcConfiguration
, but allows you to continue using
spring.data.rest.*
properties.
An SQL database can be initialized in different ways depending on what your stack is. Or of course you can do it manually as long as the database is a separate process.
JPA has features for DDL generation, and these can be set up to run on startup against the database. This is controlled through two external properties:
spring.jpa.generate-ddl
(boolean) switches the feature on and off and is vendor
independent.spring.jpa.hibernate.ddl-auto
(enum) is a Hibernate feature that controls the
behavior in a more fine-grained way. See below for more detail.You can set spring.jpa.hibernate.ddl-auto
explicitly and the standard Hibernate property
values are none
, validate
, update
, create
, create-drop
. Spring Boot chooses a
default value for you based on whether it thinks your database is embedded (default
create-drop
) or not (default none
). An embedded database is detected by looking at the
Connection
type: hsqldb
, h2
and derby
are embedded, the rest are not. Be careful
when switching from in-memory to a ‘real’ database that you don’t make assumptions about
the existence of the tables and data in the new platform. You either have to set ddl-auto
explicitly, or use one of the other mechanisms to initialize the database.
Note | |
---|---|
You can output the schema creation by enabling the |
In addition, a file named import.sql
in the root of the classpath will be executed on
startup. This can be useful for demos and for testing if you are careful, but probably
not something you want to be on the classpath in production. It is a Hibernate feature
(nothing to do with Spring).
Spring JDBC has a DataSource
initializer feature. Spring Boot enables it by default and
loads SQL from the standard locations schema.sql
and data.sql
(in the root of the
classpath). In addition Spring Boot will load the schema-${platform}.sql
and data-${platform}.sql
files (if present), where
platform
is the value of spring.datasource.platform
, e.g. you might choose to set
it to the vendor name of the database (hsqldb
, h2
, oracle
, mysql
,
postgresql
etc.). Spring Boot enables the failfast feature of the Spring JDBC
initializer by default, so if the scripts cause exceptions the application will fail
to start. The script locations can be changed by setting spring.datasource.schema
and
spring.datasource.data
, and neither location will be processed if
spring.datasource.initialize=false
.
To disable the failfast you can set spring.datasource.continueOnError=true
. This can be
useful once an application has matured and been deployed a few times, since the scripts
can act as ‘poor man’s migrations’ — inserts that fail mean that the data is already
there, so there would be no need to prevent the application from running, for instance.
If you want to use the schema.sql
initialization in a JPA app (with
Hibernate) then ddl-auto=create-drop
will lead to errors if
Hibernate tries to create the same tables. To avoid those errors set
ddl-auto
explicitly to "" (preferable) or "none". Whether or not you use
ddl-auto=create-drop
you can always use data.sql
to initialize new
data.
If you are using Spring Batch then it comes pre-packaged with SQL initialization scripts
for most popular database platforms. Spring Boot will detect your database type, and
execute those scripts by default, and in this case will switch the fail fast setting to
false (errors are logged but do not prevent the application from starting). This is
because the scripts are known to be reliable and generally do not contain bugs, so errors
are ignorable, and ignoring them makes the scripts idempotent. You can switch off the
initialization explicitly using spring.batch.initializer.enabled=false
.
Spring Boot works fine with higher level migration tools Flyway (SQL-based) and Liquibase (XML). In general we prefer Flyway because it is easier on the eyes, and it isn’t very common to need platform independence: usually only one or at most couple of platforms is needed.
To automatically run Flyway database migrations on startup, add the
org.flywaydb:flyway-core
to your classpath.
The migrations are scripts in the form V<VERSION>__<NAME>.sql
(with <VERSION>
an
underscore-separated version, e.g. ‘1’ or ‘2_1’). By default they live in a folder
classpath:db/migration
but you can modify that using flyway.locations
(a list). See
the Flyway class from flyway-core for details of available settings like schemas etc. In
addition Spring Boot provides a small set of properties in
FlywayProperties
that can be used to disable the migrations, or switch off the location checking.
By default Flyway will autowire the (@Primary
) DataSource
in your context and
use that for migrations. If you like to use a different DataSource
you can create
one and mark its @Bean
as @FlywayDataSource
- if you do that remember to create
another one and mark it as @Primary
if you want two data sources.
Or you can use Flyway’s native DataSource
by setting flyway.[url,user,password]
in external properties.
There is a Flyway sample so you can see how to set things up.
To automatically run Liquibase database migrations on startup, add the
org.liquibase:liquibase-core
to your classpath.
The master change log is by default read from db/changelog/db.changelog-master.yaml
but
can be set using liquibase.change-log
. See
LiquibaseProperties
for details of available settings like contexts, default schema etc.
There is a Liquibase sample so you can see how to set things up.
Spring Batch auto configuration is enabled by adding @EnableBatchProcessing
(from Spring Batch) somewhere in your context.
By default it executes all Jobs
in the application context on startup (see
JobLauncherCommandLineRunner
for details). You can narrow down to a specific job or jobs by specifying
spring.batch.job.names
(comma-separated job name patterns).
If the application context includes a JobRegistry
then the jobs in
spring.batch.job.names
are looked up in the registry instead of being autowired from the
context. This is a common pattern with more complex systems where multiple jobs are
defined in child contexts and registered centrally.
See BatchAutoConfiguration and @EnableBatchProcessing for more details.
In a standalone application the Actuator HTTP port defaults to the same as the main HTTP
port. To make the application listen on a different port set the external property
management.port
. To listen on a completely different network address (e.g. if you have
an internal network for management and an external one for user applications) you can
also set management.address
to a valid IP address that the server is able to bind to.
For more detail look at the
ManagementServerProperties
source code and
Section 45.3, “Customizing the management server port”
in the ‘Production-ready features’ section.
Spring Boot installs a ‘whitelabel’ error page that you will see in browser client if
you encounter a server error (machine clients consuming JSON and other media types should
see a sensible response with the right error code). To switch it off you can set
error.whitelabel.enabled=false
, but normally in addition or alternatively to that you
will want to add your own error page replacing the whitelabel one. Exactly how you do this
depends on the templating technology that you are using. For example, if you are using
Thymeleaf you would add an error.html
template and if you are using FreeMarker you would
add an error.ftl
template. In general what you need is a View
that resolves with a name
of error
, and/or a @Controller
that handles the /error
path. Unless you replaced some
of the default configuration you should find a BeanNameViewResolver
in your
ApplicationContext
so a @Bean
with id error
would be a simple way of doing that.
Look at ErrorMvcAutoConfiguration
for more options.
See also the section on Error Handling for details of how to register handlers in the servlet container.
If you define a @Configuration
with @EnableWebSecurity
anywhere in your application
it will switch off the default webapp security settings in Spring Boot. To tweak the
defaults try setting properties in security.*
(see
SecurityProperties
for details of available settings) and SECURITY
section of
Common application properties.
If you provide a @Bean
of type AuthenticationManager
the default one will not be
created, so you have the full feature set of Spring Security available (e.g.
various authentication options).
Spring Security also provides a convenient AuthenticationManagerBuilder
which can be
used to build an AuthenticationManager
with common options. The recommended way to
use this in a webapp is to inject it into a void method in a
WebSecurityConfigurerAdapter
, e.g.
@Configuration public class SecurityConfiguration extends WebSecurityConfigurerAdapter { @Autowired public void configureGlobal(AuthenticationManagerBuilder auth) throws Exception { auth.inMemoryAuthentication() .withUser("barry").password("password").roles("USER"); // ... etc. } // ... other stuff for application security }
You will get the best results if you put this in a nested class, or a standalone class
(i.e. not mixed in with a lot of other @Beans
that might be allowed to influence the
order of instantiation). The secure web sample
is a useful template to follow.
If you experience instantiation issues (e.g. using JDBC or JPA for the user detail store)
it might be worth extracting the AuthenticationManagerBuilder
callback into a
GlobalAuthenticationConfigurerAdapter
(in the init()
method so it happens before the
authentication manager is needed elsewhere), e.g.
@Configuration public class AuthenticationManagerConfiguration extends GlobalAuthenticationConfigurerAdapter { @Override public void init(AuthenticationManagerBuilder auth) { auth.inMemoryAuthentication() // ... etc. } }
Ensuring that all your main endpoints are only available over HTTPS is an important
chore for any application. If you are using Tomcat as a servlet container, then
Spring Boot will add Tomcat’s own RemoteIpValve
automatically if it detects some
environment settings, and you should be able to rely on the HttpServletRequest
to
report whether it is secure or not (even downstream of a proxy server that handles the
real SSL termination). The standard behavior is determined by the presence or absence of
certain request headers (x-forwarded-for
and x-forwarded-proto
), whose names are
conventional, so it should work with most front end proxies. You can switch on the valve
by adding some entries to application.properties
, e.g.
server.tomcat.remote_ip_header=x-forwarded-for server.tomcat.protocol_header=x-forwarded-proto
(The presence of either of those properties will switch on the valve. Or you can add the
RemoteIpValve
yourself by adding a TomcatEmbeddedServletContainerFactory
bean.)
Spring Security can also be configured to require a secure channel for all (or some
requests). To switch that on in a Spring Boot application you just need to set
security.require_ssl
to true
in application.properties
.
There are several options for hot reloading. Running in an IDE (especially with debugging on) is a good way to do development (all modern IDEs allow reloading of static resources and usually also hot-swapping of Java class changes). The Maven and Gradle plugins also support running from the command line with reloading of static files. You can use that with an external css/js compiler process if you are writing that code with higher level tools.
The spring-boot-devtools
module is also
available with support for fast application restarts and LiveReload.
Most of the templating technologies supported by Spring Boot include a configuration
option to disable caching (see below for details). If you’re using the
spring-boot-devtools
module these properties will be
automatically configured
for you at developement time.
If you are using Thymeleaf, then set spring.thymeleaf.cache
to false
. See
ThymeleafAutoConfiguration
for other Thymeleaf customization options.
If you are using FreeMarker, then set spring.freemarker.cache
to false
. See
FreeMarkerAutoConfiguration
for other FreeMarker customization options.
If you are using Groovy templates, then set spring.groovy.template.cache
to false
. See
GroovyTemplateAutoConfiguration
for other Groovy customization options.
If you are using Velocity, then set spring.velocity.cache
to false
. See
VelocityAutoConfiguration
for other Velocity customization options.
The spring-boot-devtools
module includes support for automatic application restarts.
Whilst not as fast a technologies such as JRebel
or Spring Loaded it’s usually
significantly faster than a “cold start”. You should probably give it a try before
investigating some of the more complex reload options discussed bellow.
For more details see the Chapter 20, Developer tools section.
Modern IDEs (Eclipse, IDEA, etc.) all support hot swapping of bytecode, so if you make a change that doesn’t affect class or method signatures it should reload cleanly with no side effects.
Spring Loaded goes a little further in
that it can reload class definitions with changes in the method signatures. With some
customization it can force an ApplicationContext
to refresh itself (but there is no
general mechanism to ensure that would be safe for a running application anyway, so it
would only ever be a development time trick probably).
To use Spring Loaded with the Maven command line, just add it as a dependency in the Spring Boot plugin declaration, e.g.
<plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <dependencies> <dependency> <groupId>org.springframework</groupId> <artifactId>springloaded</artifactId> <version>1.2.0.RELEASE</version> </dependency> </dependencies> </plugin>
This normally works pretty well with Eclipse and IntelliJ IDEA as long as they have their build configuration aligned with the Maven defaults (Eclipse m2e does this out of the box).
You need to jump through a few hoops if you want to use Spring Loaded in combination with Gradle and IntelliJ IDEA. By default, IntelliJ IDEA will compile classes into a different location than Gradle, causing Spring Loaded monitoring to fail.
To configure IntelliJ IDEA correctly you can use the idea
Gradle plugin:
buildscript { repositories { jcenter() } dependencies { classpath "org.springframework.boot:spring-boot-gradle-plugin:1.3.0.M2" classpath 'org.springframework:springloaded:1.2.0.RELEASE' } } apply plugin: 'idea' idea { module { inheritOutputDirs = false outputDir = file("$buildDir/classes/main/") } } // ...
Note | |
---|---|
IntelliJ IDEA must be configured to use the same Java version as the command line
Gradle task and |
You can also additionally enable ‘Make Project Automatically’ inside Intellij IDEA to automatically compile your code whenever a file is saved.
If you use a Maven build that inherits directly or indirectly from spring-boot-dependencies
(for instance spring-boot-starter-parent
) but you want to override a specific
third-party dependency you can add appropriate <properties>
elements. Browse
the spring-boot-dependencies
POM for a complete list of properties. For example, to pick a different slf4j
version
you would add the following:
<properties> <slf4j.version>1.7.5<slf4j.version> </properties>
Note | |
---|---|
This only works if your Maven project inherits (directly or indirectly) from
|
Warning | |
---|---|
Each Spring Boot release is designed and tested against a specific set of third-party dependencies. Overriding versions may cause compatibility issues. |
The spring-boot-maven-plugin
can be used to create an executable ‘fat’ JAR. If you
are using the spring-boot-starter-parent
POM you can simply declare the plugin and
your jars will be repackaged:
<build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> </plugins> </build>
If you are not using the parent POM you can still use the plugin, however, you must
additionally add an <executions>
section:
<build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <version>1.3.0.M2</version> <executions> <execution> <goals> <goal>repackage</goal> </goals> </execution> </executions> </plugin> </plugins> </build>
See the plugin documentation for full usage details.
If you want to use your project as a library jar for other projects to depend on, and in addition have an executable (e.g. demo) version of it, you will want to configure the build in a slightly different way.
For Maven the normal JAR plugin and the Spring Boot plugin both have a ‘classifier’ configuration that you can add to create an additional JAR. Example (using the Spring Boot Starter Parent to manage the plugin versions and other configuration defaults):
<build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <configuration> <classifier>exec</classifier> </configuration> </plugin> </plugins> </build>
Two jars are produced, the default one, and an executable one using the Boot plugin with classifier ‘exec’.
For Gradle users the steps are similar. Example:
bootRepackage {
classifier = 'exec'
}
Most nested libraries in an executable jar do not need to be unpacked in order to run,
however, certain libraries can have problems. For example, JRuby includes its own nested
jar support which assumes that the jruby-complete.jar
is always directly available as a
file in its own right.
To deal with any problematic libraries, you can flag that specific nested jars should be automatically unpacked to the ‘temp folder’ when the executable jar first runs.
For example, to indicate that JRuby should be flagged for unpack using the Maven Plugin you would add the following configuration:
<build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <configuration> <requiresUnpack> <dependency> <groupId>org.jruby</groupId> <artifactId>jruby-complete</artifactId> </dependency> </requiresUnpack> </configuration> </plugin> </plugins> </build>
And to do that same with Gradle:
springBoot {
requiresUnpack = ['org.jruby:jruby-complete']
}
Often if you have an executable and a non-executable jar as build products, the executable
version will have additional configuration files that are not needed in a library jar.
E.g. the application.yml
configuration file might excluded from the non-executable JAR.
Here’s how to do that in Maven:
<build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <configuration> <classifier>exec</classifier> </configuration> </plugin> <plugin> <artifactId>maven-jar-plugin</artifactId> <executions> <execution> <id>exec</id> <phase>package</phase> <goals> <goal>jar</goal> </goals> <configuration> <classifier>exec</classifier> </configuration> </execution> <execution> <phase>package</phase> <goals> <goal>jar</goal> </goals> <configuration> <!-- Need this to ensure application.yml is excluded --> <forceCreation>true</forceCreation> <excludes> <exclude>application.yml</exclude> </excludes> </configuration> </execution> </executions> </plugin> </plugins> </build>
In Gradle you can create a new JAR archive with standard task DSL features, and then have
the bootRepackage
task depend on that one using its withJarTask
property:
jar { baseName = 'spring-boot-sample-profile' version = '0.0.0' excludes = ['**/application.yml'] } task('execJar', type:Jar, dependsOn: 'jar') { baseName = 'spring-boot-sample-profile' version = '0.0.0' classifier = 'exec' from sourceSets.main.output } bootRepackage { withJarTask = tasks['execJar'] }
To attach a remote debugger to a Spring Boot application started with Maven you can use
the jvmArguments
property of the maven plugin.
Check this example for more details.
To attach a remote debugger to a Spring Boot application started with Gradle you can use
the applicationDefaultJvmArgs
in build.gradle
or --debug-jvm
command line option.
build.gradle
:
applicationDefaultJvmArgs = [
"-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005"
]
Command line:
$ gradle run --debug-jvm
Check Gradle Application Plugin for more details.
To build with Ant you need to grab dependencies, compile and then create a jar or war
archive as normal. To make it executable you can either use the spring-boot-antlib
module, or you can follow these instructions:
Main-Class
, e.g. JarLauncher
for a jar file, and
specify the other properties it needs as manifest entries, principally a Start-Class
.provided
(embedded container) dependencies in a nested lib-provided
directory.
Remember not to compress the entries in the archive.spring-boot-loader
classes at the root of the archive (so the Main-Class
is available).Example:
<target name="build" depends="compile"> <copy todir="target/classes/lib"> <fileset dir="lib/runtime" /> </copy> <jar destfile="target/spring-boot-sample-actuator-${spring-boot.version}.jar" compress="false"> <fileset dir="target/classes" /> <fileset dir="src/main/resources" /> <zipfileset src="lib/loader/spring-boot-loader-jar-${spring-boot.version}.jar" /> <manifest> <attribute name="Main-Class" value="org.springframework.boot.loader.JarLauncher" /> <attribute name="Start-Class" value="${start-class}" /> </manifest> </jar> </target>
The Actuator Sample has a build.xml
that should work if you run it with
$ ant -lib <folder containing ivy-2.2.jar>
after which you can run the application with
$ java -jar target/*.jar
If you want to use Spring Boot with Java 6 there are a small number of configuration changes that you will have to make. The exact changes depend on your application’s functionality.
If you are using one of Boot’s embedded Servlet containers you will have to use a Java 6-compatible container. Both Tomcat 7 and Jetty 8 are Java 6 compatible. See Section 67.15, “Use Tomcat 7” and Section 67.16, “Use Jetty 8” for details.
While the Java Transaction API itself doesn’t require Java 7 the official API jar
contains classes that have been built to require Java 7. If you are using JTA then
you will need to replace the official JTA 1.2 API jar with one that has been built
to work on Java 6. To do so, exclude any transitive dependencies on
javax.transaction:javax.transaction-api
and replace them with a dependency on
org.jboss.spec.javax.transaction:jboss-transaction-api_1.2_spec:1.0.0.Final
The first step in producing a deployable war file is to provide a
SpringBootServletInitializer
subclass and override its configure
method. This makes
use of Spring Framework’s Servlet 3.0 support and allows you to configure your
application when it’s launched by the servlet container. Typically, you update your
application’s main class to extend SpringBootServletInitializer
:
@SpringBootApplication public class Application extends SpringBootServletInitializer { @Override protected SpringApplicationBuilder configure(SpringApplicationBuilder application) { return application.sources(Application.class); } public static void main(String[] args) throws Exception { SpringApplication.run(Application.class, args); } }
The next step is to update your build configuration so that your project produces a war file
rather than a jar file. If you’re using Maven and using spring-boot-starter-parent
(which
configures Maven’s war plugin for you) all you need to do is modify pom.xml
to change the
packaging to war:
<packaging>war</packaging>
If you’re using Gradle, you need to modify build.gradle
to apply the war plugin to the
project:
apply plugin: 'war'
The final step in the process is to ensure that the embedded servlet container doesn’t interfere with the servlet container to which the war file will be deployed. To do so, you need to mark the embedded servlet container dependency as provided.
If you’re using Maven:
<dependencies> <!-- … --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-tomcat</artifactId> <scope>provided</scope> </dependency> <!-- … --> </dependencies>
And if you’re using Gradle:
dependencies { // … providedRuntime 'org.springframework.boot:spring-boot-starter-tomcat' // … }
If you’re using the Spring Boot build tools,
marking the embedded servlet container dependency as provided will produce an executable war
file with the provided dependencies packaged in a lib-provided
directory. This means
that, in addition to being deployable to a servlet container, you can also run your
application using java -jar
on the command line.
Tip | |
---|---|
Take a look at Spring Boot’s sample applications for a Maven-based example of the above-described configuration. |
Older Servlet containers don’t have support for the ServletContextInitializer
bootstrap
process used in Servlet 3.0. You can still use Spring and Spring Boot in these containers
but you are going to need to add a web.xml
to your application and configure it to load
an ApplicationContext
via a DispatcherServlet
.
For a non-web application it should be easy (throw away the code that creates your
ApplicationContext
and replace it with calls to SpringApplication
or
SpringApplicationBuilder
). Spring MVC web applications are generally amenable to first
creating a deployable war application, and then migrating it later to an executable war
and/or jar. Useful reading is in the Getting
Started Guide on Converting a jar to a war.
Create a deployable war by extending SpringBootServletInitializer
(e.g. in a class
called Application
), and add the Spring Boot @EnableAutoConfiguration
annotation.
Example:
@Configuration @EnableAutoConfiguration @ComponentScan public class Application extends SpringBootServletInitializer { @Override protected SpringApplicationBuilder configure(SpringApplicationBuilder application) { // Customize the application or call application.sources(...) to add sources // Since our example is itself a @Configuration class we actually don't // need to override this method. return application; } }
Remember that whatever you put in the sources
is just a Spring ApplicationContext
and
normally anything that already works should work here. There might be some beans you can
remove later and let Spring Boot provide its own defaults for them, but it should be
possible to get something working first.
Static resources can be moved to /public
(or /static
or /resources
or
/META-INF/resources
) in the classpath root. Same for messages.properties
(Spring Boot
detects this automatically in the root of the classpath).
Vanilla usage of Spring DispatcherServlet
and Spring Security should require no further
changes. If you have other features in your application, using other servlets or filters
for instance, then you may need to add some configuration to your Application
context,
replacing those elements from the web.xml
as follows:
@Bean
of type Servlet
or ServletRegistrationBean
installs that bean in the
container as if it was a <servlet/>
and <servlet-mapping/>
in web.xml
.@Bean
of type Filter
or FilterRegistrationBean
behaves similarly (like a
<filter/>
and <filter-mapping/>
.ApplicationContext
in an XML file can be added to an @Import
in your
Application
. Or simple cases where annotation configuration is heavily used already
can be recreated in a few lines as @Bean
definitions.Once the war is working we make it executable by adding a main
method to our
Application
, e.g.
public static void main(String[] args) { SpringApplication.run(Application.class, args); }
Applications can fall into more than one category:
web.xml
.web.xml
.All of these should be amenable to translation, but each might require slightly different tricks.
Servlet 3.0+ applications might translate pretty easily if they already use the Spring
Servlet 3.0+ initializer support classes. Normally all the code from an existing
WebApplicationInitializer
can be moved into a SpringBootServletInitializer
. If your
existing application has more than one ApplicationContext
(e.g. if it uses
AbstractDispatcherServletInitializer
) then you might be able to squash all your context
sources into a single SpringApplication
. The main complication you might encounter is if
that doesn’t work and you need to maintain the context hierarchy. See the
entry on building a hierarchy for
examples. An existing parent context that contains web-specific features will usually
need to be broken up so that all the ServletContextAware
components are in the child
context.
Applications that are not already Spring applications might be convertible to a Spring Boot application, and the guidance above might help, but your mileage may vary.
To deploy a Spring Boot application to Weblogic you must ensure that your servlet
initializer directly implements WebApplicationInitializer
(even if you extend from a
base class that already implements it).
A typical initializer for Weblogic would be something like this:
import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.boot.context.web.SpringBootServletInitializer; import org.springframework.web.WebApplicationInitializer; @SpringBootApplication public class MyApplication extends SpringBootServletInitializer implements WebApplicationInitializer { }
If you use logback, you will also need to tell Weblogic to prefer the packaged version
rather than the version that pre-installed with the server. You can do this by adding a
WEB-INF/weblogic.xml
file with the following contents:
<?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 http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd http://xmlns.oracle.com/weblogic/weblogic-web-app http://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>
Spring Boot uses Servlet 3.0 APIs to initialize the ServletContext
(register Servlets
etc.) so you can’t use the same application out of the box in a Servlet 2.5 container.
It is however possible to run a Spring Boot application on an older container with some
special tools. If you include org.springframework.boot:spring-boot-legacy
as a
dependency (maintained separately to the
core of Spring Boot and currently available at 1.0.0.RELEASE), all you should need to do
is create a web.xml
and declare a context listener to create the application context and
your filters and servlets. The context listener is a special purpose one for Spring Boot,
but the rest of it is normal for a Spring application in Servlet 2.5. Example:
<?xml version="1.0" encoding="UTF-8"?> <web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"> <context-param> <param-name>contextConfigLocation</param-name> <param-value>demo.Application</param-value> </context-param> <listener> <listener-class>org.springframework.boot.legacy.context.web.SpringBootContextLoaderListener</listener-class> </listener> <filter> <filter-name>metricFilter</filter-name> <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class> </filter> <filter-mapping> <filter-name>metricFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> <servlet> <servlet-name>appServlet</servlet-name> <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class> <init-param> <param-name>contextAttribute</param-name> <param-value>org.springframework.web.context.WebApplicationContext.ROOT</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>appServlet</servlet-name> <url-pattern>/</url-pattern> </servlet-mapping> </web-app>
In this example we are using a single application context (the one created by the context
listener) and attaching it to the DispatcherServlet
using an init parameter. This is
normal in a Spring Boot application (you normally only have one application context).
Various properties can be specified inside your application.properties
/application.yml
file or as command line switches. This section provides a list common Spring Boot
properties and references to the underlying classes that consume them.
Note | |
---|---|
Property contributions can come from additional jar files on your classpath so you should not consider this an exhaustive list. It is also perfectly legit to define your own properties. |
Warning | |
---|---|
This sample file is meant as a guide only. Do not copy/paste the entire content into your application; rather pick only the properties that you need. |
# =================================================================== # COMMON SPRING BOOT PROPERTIES # # This sample file is provided as a guideline. Do NOT copy it in its # entirety to your own application. ^^^ # =================================================================== # ---------------------------------------- # CORE PROPERTIES # ---------------------------------------- # BANNER banner.charset=UTF-8 # banner file encoding banner.location=classpath:banner.txt # banner file location # SPRING CONFIG (ConfigFileApplicationListener) spring.config.name= # config file name (default to 'application') spring.config.location= # location of config file # PROFILES spring.profiles.active= # comma list of active profiles spring.profiles.include= # unconditionally activate the specified comma separated profiles # APPLICATION SETTINGS (SpringApplication) spring.main.sources= # sources (class name, package name or XML resource location) to include spring.main.web-environment= # detect by default spring.main.show-banner=true spring.main....= # see class for all properties # ADMIN (SpringApplicationAdminJmxAutoConfiguration) spring.application.admin.enabled=false # enable admin features for the application spring.application.admin.jmx-name=org.springframework.boot:type=Admin,name=SpringApplication # JMX name of the application admin MBean # OUTPUT spring.output.ansi.enabled=detect # Configure the ANSI output ("detect", "always", "never") # LOGGING logging.path=/var/log logging.file=myapp.log logging.config= # location of config file (default classpath:logback.xml for logback) logging.level.*= # levels for loggers, e.g. "logging.level.org.springframework=DEBUG" (TRACE, DEBUG, INFO, WARN, ERROR, FATAL, OFF) # IDENTITY (ContextIdApplicationContextInitializer) spring.application.name= spring.application.index= # EMBEDDED SERVER CONFIGURATION (ServerProperties) server.port=8080 server.address= # bind to a specific NIC server.compression.enabled=false # if response compression is enabled server.compression.mime-types=text/html,text/xml,text/plain,text/css # comma-separated list of MIME types that should be compressed server.compression.min-response-size=2048 # minimum response size that is required for compression to be performed server.context-parameters.*= # Servlet context init parameters, e.g. server.context-parameters.a=alpha server.context-path= # the context path, defaults to '/' server.jsp-servlet.class-name=org.apache.jasper.servlet.JspServlet # The class name of the JSP servlet server.jsp-servlet.init-parameters.*= # Init parameters used to configure the JSP servlet server.jsp-servlet.registered=true # Whether or not the JSP servlet is registered server.servlet-path= # the servlet path, defaults to '/' server.display-name= # the display name of the application server.session.timeout= # session timeout in seconds server.session.tracking-modes= # tracking modes (one or more of "cookie" ,"url", "ssl") server.session.cookie.name= # session cookie name server.session.cookie.domain= # domain for the session cookie server.session.cookie.path= # path of the session cookie server.session.cookie.comment= # comment for the session cookie server.session.cookie.http-only= # "HttpOnly" flag for the session cookie server.session.cookie.secure= # "Secure" flag for the session cookie server.session.cookie.max-age= # maximum age of the session cookie in seconds server.ssl.enabled=true # if SSL support is enabled server.ssl.client-auth= # want or need server.ssl.key-alias= server.ssl.ciphers= # supported SSL ciphers server.ssl.key-password= server.ssl.key-store= server.ssl.key-store-password= server.ssl.key-store-provider= server.ssl.key-store-type= server.ssl.protocol=TLS server.ssl.trust-store= server.ssl.trust-store-password= server.ssl.trust-store-provider= server.ssl.trust-store-type= server.tomcat.access-log-pattern= # log pattern of the access log server.tomcat.access-log-enabled=false # is access logging enabled server.tomcat.internal-proxies=10\\.\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}|\\ 192\\.168\\.\\d{1,3}\\.\\d{1,3}|\\ 169\\.254\\.\\d{1,3}\\.\\d{1,3}|\\ 127\\.\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}|\\ 172\\.1[6-9]{1}\\.\\d{1,3}\\.\\d{1,3}|\\ 172\\.2[0-9]{1}\\.\\d{1,3}\\.\\d{1,3}|\\ 172\\.3[0-1]{1}\\.\\d{1,3}\\.\\d{1,3} # regular expression matching trusted IP addresses server.tomcat.protocol-header=x-forwarded-proto # front end proxy forward header server.tomcat.protocol-header-https-value=https # value of the protocol header that indicates that the incoming request uses SSL server.tomcat.port-header= # front end proxy port header server.tomcat.remote-ip-header=x-forwarded-for server.tomcat.basedir=/tmp # base dir (usually not needed, defaults to tmp) server.tomcat.background-processor-delay=30; # in seconds server.tomcat.max-http-header-size= # maximum size in bytes of the HTTP message header server.tomcat.max-threads = 0 # number of threads in protocol handler server.tomcat.uri-encoding = UTF-8 # character encoding to use for URL decoding server.undertow.access-log-enabled=false # if access logging is enabled server.undertow.access-log-pattern=common # log pattern of the access log server.undertow.access-log-dir=logs # access logs directory server.undertow.buffer-size= # size of each buffer in bytes server.undertow.buffers-per-region= # number of buffer per region server.undertow.direct-buffers=false # allocate buffers outside the Java heap server.undertow.io-threads= # number of I/O threads to create for the worker server.undertow.worker-threads= # number of worker threads # SPRING MVC (WebMvcProperties) spring.mvc.locale= # set fixed locale, e.g. en_UK spring.mvc.date-format= # set fixed date format, e.g. dd/MM/yyyy spring.mvc.favicon.enabled=true spring.mvc.message-codes-resolver-format= # PREFIX_ERROR_CODE / POSTFIX_ERROR_CODE spring.mvc.ignore-default-model-on-redirect=true # if the the content of the "default" model should be ignored redirects spring.mvc.async.request-timeout= # async request timeout in milliseconds spring.mvc.view.prefix= # MVC view prefix spring.mvc.view.suffix= # ... and suffix # SPRING RESOURCES HANDLING (ResourceProperties) spring.resources.cache-period= # cache timeouts in headers sent to browser spring.resources.add-mappings=true # if default mappings should be added spring.resources.static-locations= # comma-separated list of the locations that serve static content (e.g. 'classpath:/resources/') spring.resources.chain.enabled=false # enable the Spring Resource Handling chain (enabled automatically if at least a strategy is enabled) spring.resources.chain.cache=false # enable in-memory caching of resource resolution spring.resources.chain.html-application-cache=false # enable HTML5 appcache manifest rewriting spring.resources.chain.strategy.content.enabled=false # enable a content version strategy spring.resources.chain.strategy.content.paths= # comma-separated list of regular expression patterns to apply the version strategy to spring.resources.chain.strategy.fixed.enabled=false # enable a fixed version strategy spring.resources.chain.strategy.fixed.paths= # comma-separated list of regular expression patterns to apply the version strategy to spring.resources.chain.strategy.fixed.version= # version string to use for this version strategy # MULTIPART (MultipartProperties) multipart.enabled=true multipart.file-size-threshold=0 # Threshold after which files will be written to disk. multipart.location= # Intermediate location of uploaded files. multipart.max-file-size=1Mb # Max file size. multipart.max-request-size=10Mb # Max request size. # SPRING HATEOAS (HateoasProperties) spring.hateoas.apply-to-primary-object-mapper=true # if the primary mapper should also be configured # HTTP encoding (HttpEncodingProperties) spring.http.encoding.charset=UTF-8 # the encoding of HTTP requests/responses spring.http.encoding.enabled=true # enable http encoding support spring.http.encoding.force=true # force the configured encoding # HTTP message conversion spring.http.converters.preferred-json-mapper= # the preferred JSON mapper to use for HTTP message conversion. Set to "gson" to force the use of Gson when both it and Jackson are on the classpath. # JACKSON (JacksonProperties) spring.jackson.date-format= # Date format string (e.g. yyyy-MM-dd HH:mm:ss), or a fully-qualified date format class name (e.g. com.fasterxml.jackson.databind.util.ISO8601DateFormat) spring.jackson.property-naming-strategy= # One of the constants on Jackson's PropertyNamingStrategy (e.g. CAMEL_CASE_TO_LOWER_CASE_WITH_UNDERSCORES) or the fully-qualified class name of a PropertyNamingStrategy subclass spring.jackson.deserialization.*= # see Jackson's DeserializationFeature spring.jackson.generator.*= # see Jackson's JsonGenerator.Feature spring.jackson.joda-date-time-format= # Joda date time format string spring.jackson.mapper.*= # see Jackson's MapperFeature spring.jackson.parser.*= # see Jackson's JsonParser.Feature spring.jackson.serialization.*= # see Jackson's SerializationFeature spring.jackson.serialization-inclusion= # Controls the inclusion of properties during serialization (see Jackson's JsonInclude.Include) # THYMELEAF (ThymeleafAutoConfiguration) spring.thymeleaf.check-template-location=true spring.thymeleaf.prefix=classpath:/templates/ spring.thymeleaf.excluded-view-names= # comma-separated list of view names that should be excluded from resolution spring.thymeleaf.view-names= # comma-separated list of view names that can be resolved spring.thymeleaf.suffix=.html spring.thymeleaf.mode=HTML5 spring.thymeleaf.enabled=true # enable MVC view resolution spring.thymeleaf.encoding=UTF-8 spring.thymeleaf.content-type=text/html # ;charset=<encoding> is added spring.thymeleaf.cache=true # set to false for hot refresh # FREEMARKER (FreeMarkerAutoConfiguration) spring.freemarker.allow-request-override=false spring.freemarker.cache=true spring.freemarker.check-template-location=true spring.freemarker.charset=UTF-8 spring.freemarker.content-type=text/html spring.freemarker.enabled=true # enable MVC view resolution spring.freemarker.expose-request-attributes=false spring.freemarker.expose-session-attributes=false spring.freemarker.expose-spring-macro-helpers=false spring.freemarker.prefix= spring.freemarker.prefer-file-system-access=true # prefer file system access for template loading spring.freemarker.request-context-attribute= spring.freemarker.settings.*= spring.freemarker.suffix=.ftl spring.freemarker.template-loader-path=classpath:/templates/ # comma-separated list spring.freemarker.view-names= # whitelist of view names that can be resolved # GROOVY TEMPLATES (GroovyTemplateAutoConfiguration) spring.groovy.template.cache=true spring.groovy.template.charset=UTF-8 spring.groovy.template.check-template-location=true # check that the templates location exists spring.groovy.template.configuration.*= # See GroovyMarkupConfigurer spring.groovy.template.content-type=text/html spring.groovy.template.enabled=true # enable MVC view resolution spring.groovy.template.prefix= spring.groovy.template.resource-loader-path=classpath:/templates/ spring.groovy.template.suffix=.tpl spring.groovy.template.view-names= # whitelist of view names that can be resolved # VELOCITY TEMPLATES (VelocityAutoConfiguration) spring.velocity.allow-request-override=false spring.velocity.cache=true spring.velocity.check-template-location=true spring.velocity.charset=UTF-8 spring.velocity.content-type=text/html spring.velocity.date-tool-attribute= spring.velocity.enabled=true # enable MVC view resolution spring.velocity.expose-request-attributes=false spring.velocity.expose-session-attributes=false spring.velocity.expose-spring-macro-helpers=false spring.velocity.number-tool-attribute= spring.velocity.prefer-file-system-access=true # prefer file system access for template loading spring.velocity.prefix= spring.velocity.properties.*= spring.velocity.request-context-attribute= spring.velocity.resource-loader-path=classpath:/templates/ spring.velocity.suffix=.vm spring.velocity.toolbox-config-location= # velocity Toolbox config location, for example "/WEB-INF/toolbox.xml" spring.velocity.view-names= # whitelist of view names that can be resolved # MUSTACHE TEMPLATES (MustacheAutoConfiguration) spring.mustache.cache=true spring.mustache.charset=UTF-8 spring.mustache.check-template-location=true spring.mustache.content-type=UTF-8 spring.mustache.enabled=true # enable MVC view resolution spring.mustache.prefix= spring.mustache.suffix=.html spring.mustache.view-names= # whitelist of view names that can be resolved # JERSEY (JerseyProperties) spring.jersey.type=servlet # servlet or filter spring.jersey.init= # init params spring.jersey.filter.order= # INTERNATIONALIZATION (MessageSourceAutoConfiguration) spring.messages.basename=messages spring.messages.cache-seconds=-1 spring.messages.encoding=UTF-8 # SECURITY (SecurityProperties) security.user.name=user # login username security.user.password= # login password security.user.role=USER # role assigned to the user security.require-ssl=false # advanced settings ... security.enable-csrf=false security.basic.enabled=true security.basic.realm=Spring security.basic.path= # /** security.basic.authorize-mode= # ROLE, AUTHENTICATED, NONE security.filter-order=0 security.headers.xss=false security.headers.cache=false security.headers.frame=false security.headers.content-type=false security.headers.hsts=all # none / domain / all security.sessions=stateless # always / never / if_required / stateless security.ignored= # Comma-separated list of paths to exclude from the default secured paths # SECURITY OAUTH2 CLIENT (OAuth2ClientProperties security.oauth2.client.client-id= # OAuth2 client id security.oauth2.client.client-secret= # OAuth2 client secret. A random secret is generated by default # SECURITY OAUTH2 SSO (OAuth2SsoProperties security.oauth2.sso.filter-order= # Filter order to apply if not providing an explicit WebSecurityConfigurerAdapter security.oauth2.sso.login-path= # Path to the login page, i.e. the one that triggers the redirect to the OAuth2 Authorization Server # DATASOURCE (DataSourceAutoConfiguration & DataSourceProperties) spring.datasource.name= # name of the data source spring.datasource.initialize=true # populate using data.sql spring.datasource.schema= # a schema (DDL) script resource reference spring.datasource.data= # a data (DML) script resource reference spring.datasource.sql-script-encoding= # a charset for reading SQL scripts spring.datasource.platform= # the platform to use in the schema resource (schema-${platform}.sql) spring.datasource.continue-on-error=false # continue even if can't be initialized spring.datasource.separator=; # statement separator in SQL initialization scripts spring.datasource.driver-class-name= # JDBC Settings... spring.datasource.url= spring.datasource.username= spring.datasource.password= spring.datasource.jndi-name= # For JNDI lookup (class, url, username & password are ignored when set) spring.datasource.max-active=100 # Advanced configuration... spring.datasource.max-idle=8 spring.datasource.min-idle=8 spring.datasource.initial-size=10 spring.datasource.validation-query= spring.datasource.test-on-borrow=false spring.datasource.test-on-return=false spring.datasource.test-while-idle= spring.datasource.time-between-eviction-runs-millis= spring.datasource.min-evictable-idle-time-millis= spring.datasource.max-wait= spring.datasource.jmx-enabled=false # Export JMX MBeans (if supported) # DAO (PersistenceExceptionTranslationAutoConfiguration) spring.dao.exceptiontranslation.enabled=true # MONGODB (MongoProperties) spring.data.mongodb.host= # the db host spring.data.mongodb.port=27017 # the connection port (defaults to 27107) spring.data.mongodb.uri=mongodb://localhost/test # connection URL spring.data.mongodb.database= spring.data.mongodb.authentication-database= spring.data.mongodb.grid-fs-database= spring.data.mongodb.username= spring.data.mongodb.password= spring.data.mongodb.repositories.enabled=true # if spring data repository support is enabled spring.data.mongodb.field-naming-strategy= # fully qualified name of the FieldNamingStrategy to use # JPA (JpaBaseConfiguration, HibernateJpaAutoConfiguration) spring.jpa.properties.*= # properties to set on the JPA connection spring.jpa.open-in-view=true spring.jpa.show-sql=true spring.jpa.database-platform= spring.jpa.database= spring.jpa.generate-ddl=false # ignored by Hibernate, might be useful for other vendors spring.jpa.hibernate.naming-strategy= # naming classname spring.jpa.hibernate.ddl-auto= # defaults to create-drop for embedded dbs spring.data.jpa.repositories.enabled=true # if spring data repository support is enabled # JTA (JtaAutoConfiguration) spring.jta.log-dir= # transaction log dir spring.jta.*= # technology specific configuration # JOOQ (JooqAutoConfiguration) spring.jooq.sql-dialect= # ATOMIKOS spring.jta.atomikos.connectionfactory.borrow-connection-timeout=30 # Timeout, in seconds, for borrowing connections from the pool spring.jta.atomikos.connectionfactory.ignore-session-transacted-flag=true # Whether or not to ignore the transacted flag when creating session spring.jta.atomikos.connectionfactory.local-transaction-mode=false # Whether or not local transactions are desired spring.jta.atomikos.connectionfactory.maintenance-interval=60 # The time, in seconds, between runs of the pool's maintenance thread spring.jta.atomikos.connectionfactory.max-idle-time=60 # The time, in seconds, after which connections are cleaned up from the pool spring.jta.atomikos.connectionfactory.max-lifetime=0 # The time, in seconds, that a connection can be pooled for before being destroyed. 0 denotes no limit. spring.jta.atomikos.connectionfactory.max-pool-size=1 # The maximum size of the pool spring.jta.atomikos.connectionfactory.min-pool-size=1 # The minimum size of the pool spring.jta.atomikos.connectionfactory.reap-timeout=0 # The reap timeout, in seconds, for borrowed connections. 0 denotes no limit. spring.jta.atomikos.connectionfactory.unique-resource-name=jmsConnectionFactory # The unique name used to identify the resource during recovery spring.jta.atomikos.datasource.borrow-connection-timeout=30 # Timeout, in seconds, for borrowing connections from the pool spring.jta.atomikos.datasource.default-isolation-level= # Default isolation level of connections provided by the pool spring.jta.atomikos.datasource.login-timeout= # Timeout, in seconds, for establishing a database connection spring.jta.atomikos.datasource.maintenance-interval=60 # The time, in seconds, between runs of the pool's maintenance thread spring.jta.atomikos.datasource.max-idle-time=60 # The time, in seconds, after which connections are cleaned up from the pool spring.jta.atomikos.datasource.max-lifetime=0 # The time, in seconds, that a connection can be pooled for before being destroyed. 0 denotes no limit. spring.jta.atomikos.datasource.max-pool-size=1 # The maximum size of the pool spring.jta.atomikos.datasource.min-pool-size=1 # The minimum size of the pool spring.jta.atomikos.datasource.reap-timeout=0 # The reap timeout, in seconds, for borrowed connections. 0 denotes no limit. spring.jta.atomikos.datasource.test-query= # SQL query or statement used to validate a connection before returning it spring.jta.atomikos.datasource.unique-resource-name=dataSource # The unique name used to identify the resource during recovery # BITRONIX spring.jta.bitronix.connectionfactory.acquire-increment=1 # Number of connections to create when growing the pool spring.jta.bitronix.connectionfactory.acquisition-interval=1 # Time, in seconds, to wait before trying to acquire a connection again after an invalid connection was acquired spring.jta.bitronix.connectionfactory.acquisition-timeout=30 # Timeout, in seconds, for acquiring connections from the pool spring.jta.bitronix.connectionfactory.allow-local-transactions=true # Whether or not the transaction manager should allow mixing XA and non-XA transactions spring.jta.bitronix.connectionfactory.apply-transaction-timeout=false # Whether or not the transaction timeout should be set on the XAResource when it is enlisted spring.jta.bitronix.connectionfactory.automatic-enlisting-enabled=true # Whether or not resources should be enlisted and delisted automatically spring.jta.bitronix.connectionfactory.cache-producers-consumers=true # Whether or not produces and consumers should be cached spring.jta.bitronix.connectionfactory.defer-connection-release=true # Whether or not the provider can run many transactions on the same connection and supports transaction interleaving spring.jta.bitronix.connectionfactory.ignore-recovery-failures=false # Whether or not recovery failures should be ignored spring.jta.bitronix.connectionfactory.max-idle-time=60 # The time, in seconds, after which connections are cleaned up from the pool spring.jta.bitronix.connectionfactory.max-pool-size=10 # The maximum size of the pool. 0 denotes no limit spring.jta.bitronix.connectionfactory.min-pool-size=0 # The minimum size of the pool spring.jta.bitronix.connectionfactory.password= # The password to use to connect to the JMS provider spring.jta.bitronix.connectionfactory.share-transaction-connections=false # Whether or not connections in the ACCESSIBLE state can be shared within the context of a transaction spring.jta.bitronix.connectionfactory.test-connections=true # Whether or not connections should be tested when acquired from the pool spring.jta.bitronix.connectionfactory.two-pc-ordering-position=1 # The postion that this resource should take during two-phase commit (always first is Integer.MIN_VALUE, always last is Integer.MAX_VALUE) spring.jta.bitronix.connectionfactory.unique-name=jmsConnectionFactory # The unique name used to identify the resource during recovery spring.jta.bitronix.connectionfactory.use-tm-join=true Whether or not TMJOIN should be used when starting XAResources spring.jta.bitronix.connectionfactory.user= # The user to use to connect to the JMS provider spring.jta.bitronix.datasource.acquire-increment=1 # Number of connections to create when growing the pool spring.jta.bitronix.datasource.acquisition-interval=1 # Time, in seconds, to wait before trying to acquire a connection again after an invalid connection was acquired spring.jta.bitronix.datasource.acquisition-timeout=30 # Timeout, in seconds, for acquiring connections from the pool spring.jta.bitronix.datasource.allow-local-transactions=true # Whether or not the transaction manager should allow mixing XA and non-XA transactions spring.jta.bitronix.datasource.apply-transaction-timeout=false # Whether or not the transaction timeout should be set on the XAResource when it is enlisted spring.jta.bitronix.datasource.automatic-enlisting-enabled=true # Whether or not resources should be enlisted and delisted automatically spring.jta.bitronix.datasource.cursor-holdability= # The default cursor holdability for connections spring.jta.bitronix.datasource.defer-connection-release=true # Whether or not the database can run many transactions on the same connection and supports transaction interleaving spring.jta.bitronix.datasource.enable-jdbc4-connection-test= # Whether or not Connection.isValid() is called when acquiring a connection from the pool spring.jta.bitronix.datasource.ignore-recovery-failures=false # Whether or not recovery failures should be ignored spring.jta.bitronix.datasource.isolation-level= # The default isolation level for connections spring.jta.bitronix.datasource.local-auto-commit= # The default auto-commit mode for local transactions spring.jta.bitronix.datasource.login-timeout= # Timeout, in seconds, for establishing a database connection spring.jta.bitronix.datasource.max-idle-time=60 # The time, in seconds, after which connections are cleaned up from the pool spring.jta.bitronix.datasource.max-pool-size=10 # The maximum size of the pool. 0 denotes no limit spring.jta.bitronix.datasource.min-pool-size=0 # The minimum size of the pool spring.jta.bitronix.datasource.prepared-statement-cache-size=0 # The target size of the prepared statement cache. 0 disables the cache spring.jta.bitronix.datasource.share-transaction-connections=false # Whether or not connections in the ACCESSIBLE state can be shared within the context of a transaction spring.jta.bitronix.datasource.test-query= # SQL query or statement used to validate a connection before returning it spring.jta.bitronix.datasource.two-pc-ordering-position=1 # The position that this resource should take during two-phase commit (always first is Integer.MIN_VALUE, always last is Integer.MAX_VALUE) spring.jta.bitronix.datasource.unique-name=dataSource # The unique name used to identify the resource during recovery spring.jta.bitronix.datasource.use-tm-join=true Whether or not TMJOIN should be used when starting XAResources # SOLR (SolrProperties) spring.data.solr.host=http://127.0.0.1:8983/solr spring.data.solr.zk-host= spring.data.solr.repositories.enabled=true # if spring data repository support is enabled # ELASTICSEARCH (ElasticsearchProperties) spring.data.elasticsearch.cluster-name= # The cluster name (defaults to elasticsearch) spring.data.elasticsearch.cluster-nodes= # The address(es) of the server node (comma-separated; if not specified starts a client node) spring.data.elasticsearch.properties.*= # Additional properties used to configure the client spring.data.elasticsearch.repositories.enabled=true # if spring data repository support is enabled # DATA REST (RepositoryRestConfiguration) spring.data.rest.base-path= # base path against which the exporter should calculate its links # FLYWAY (FlywayProperties) flyway.*= # Any public property available on the auto-configured `Flyway` object flyway.check-location=false # check that migration scripts location exists flyway.locations=classpath:db/migration # locations of migrations scripts flyway.schemas= # schemas to update flyway.init-version= 1 # version to start migration flyway.init-sqls= # SQL statements to execute to initialize a connection immediately after obtaining it flyway.sql-migration-prefix=V flyway.sql-migration-suffix=.sql flyway.enabled=true flyway.url= # JDBC url if you want Flyway to create its own DataSource flyway.user= # JDBC username if you want Flyway to create its own DataSource flyway.password= # JDBC password if you want Flyway to create its own DataSource # LIQUIBASE (LiquibaseProperties) liquibase.change-log=classpath:/db/changelog/db.changelog-master.yaml liquibase.check-change-log-location=true # check the change log location exists liquibase.contexts= # runtime contexts to use liquibase.default-schema= # default database schema to use liquibase.drop-first=false liquibase.enabled=true liquibase.url= # specific JDBC url (if not set the default datasource is used) liquibase.user= # user name for liquibase.url liquibase.password= # password for liquibase.url # JMX spring.jmx.default-domain= # JMX domain name spring.jmx.enabled=true # Expose MBeans from Spring spring.jmx.server=mbeanServer # MBeanServer bean name # RABBIT (RabbitProperties) spring.rabbitmq.addresses= # connection addresses (e.g. myhost:9999,otherhost:1111) spring.rabbitmq.dynamic=true # create an AmqpAdmin bean spring.rabbitmq.host= # connection host spring.rabbitmq.port= # connection port spring.rabbitmq.password= # login password spring.rabbitmq.requested-heartbeat= # requested heartbeat timeout, in seconds; zero for none spring.rabbitmq.ssl.enabled=false # enable SSL support spring.rabbitmq.ssl.key-store= # path to the key store that holds the SSL certificate spring.rabbitmq.ssl.key-store-password= # password used to access the key store spring.rabbitmq.ssl.trust-store= # trust store that holds SSL certificates spring.rabbitmq.ssl.trust-store-password= # password used to access the trust store spring.rabbitmq.username= # login user spring.rabbitmq.virtual-host= # virtual host to use when connecting to the broker # REDIS (RedisProperties) spring.redis.database= # database name spring.redis.host=localhost # server host spring.redis.password= # server password spring.redis.port=6379 # connection port spring.redis.pool.max-idle=8 # pool settings ... spring.redis.pool.min-idle=0 spring.redis.pool.max-active=8 spring.redis.pool.max-wait=-1 spring.redis.sentinel.master= # name of Redis server spring.redis.sentinel.nodes= # comma-separated list of host:port pairs spring.redis.timeout= # connection timeout in milliseconds # ACTIVEMQ (ActiveMQProperties) spring.activemq.broker-url=tcp://localhost:61616 # connection URL spring.activemq.user= spring.activemq.password= spring.activemq.in-memory=true # broker kind to create if no broker-url is specified spring.activemq.pooled=false # ARTEMIS (ArtemisProperties) spring.artemis.mode= # connection mode (native, embedded) spring.artemis.host=localhost # hornetQ host (native mode) spring.artemis.port=5445 # hornetQ port (native mode) spring.artemis.embedded.enabled=true # if the embedded server is enabled (needs hornetq-jms-server.jar) spring.artemis.embedded.server-id= # auto-generated id of the embedded server (integer) spring.artemis.embedded.persistent=false # message persistence spring.artemis.embedded.data-directory= # location of data content (when persistence is enabled) spring.artemis.embedded.queues= # comma-separated queues to create on startup spring.artemis.embedded.topics= # comma-separated topics to create on startup spring.artemis.embedded.cluster-password= # customer password (randomly generated by default) # HORNETQ (HornetQProperties) spring.hornetq.mode= # connection mode (native, embedded) spring.hornetq.host=localhost # hornetQ host (native mode) spring.hornetq.port=5445 # hornetQ port (native mode) spring.hornetq.embedded.enabled=true # if the embedded server is enabled (needs hornetq-jms-server.jar) spring.hornetq.embedded.server-id= # auto-generated id of the embedded server (integer) spring.hornetq.embedded.persistent=false # message persistence spring.hornetq.embedded.data-directory= # location of data content (when persistence is enabled) spring.hornetq.embedded.queues= # comma-separated queues to create on startup spring.hornetq.embedded.topics= # comma-separated topics to create on startup spring.hornetq.embedded.cluster-password= # customer password (randomly generated by default) # JMS (JmsProperties) spring.jms.jndi-name= # JNDI location of a JMS ConnectionFactory spring.jms.pub-sub-domain= # false for queue (default), true for topic # Email (MailProperties) spring.mail.host=smtp.acme.org # mail server host spring.mail.port= # mail server port spring.mail.username= spring.mail.password= spring.mail.default-encoding=UTF-8 # encoding to use for MimeMessages spring.mail.properties.*= # properties to set on the JavaMail session spring.mail.jndi-name= # JNDI location of a Mail Session spring.mail.test-connection=false # Test that the mail server is available on startup # SPRING BATCH (BatchProperties) spring.batch.job.names=job1,job2 spring.batch.job.enabled=true spring.batch.initializer.enabled=true spring.batch.schema= # batch schema to load spring.batch.table-prefix= # table prefix for all the batch meta-data tables # SPRING CACHE (CacheProperties) spring.cache.type= # generic, ehcache, hazelcast, infinispan, jcache, redis, guava, simple, none spring.cache.cache-names= # cache names to create on startup spring.cache.ehcache.config= # location of the ehcache configuration spring.cache.hazelcast.config= # location of the hazelcast configuration spring.cache.infinispan.config= # location of the infinispan configuration spring.cache.jcache.config= # location of jcache configuration spring.cache.jcache.provider= # fully qualified name of the CachingProvider implementation to use spring.cache.guava.spec= # guava specs # AOP spring.aop.auto= spring.aop.proxy-target-class= # FILE ENCODING (FileEncodingApplicationListener) spring.mandatory-file-encoding= # Expected character encoding the application must use # SPRING SOCIAL (SocialWebAutoConfiguration) spring.social.auto-connection-views=true # Set to true for default connection views or false if you provide your own # SPRING SOCIAL FACEBOOK (FacebookAutoConfiguration) spring.social.facebook.app-id= # your application's Facebook App ID spring.social.facebook.app-secret= # your application's Facebook App Secret # SPRING SOCIAL LINKEDIN (LinkedInAutoConfiguration) spring.social.linkedin.app-id= # your application's LinkedIn App ID spring.social.linkedin.app-secret= # your application's LinkedIn App Secret # SPRING SOCIAL TWITTER (TwitterAutoConfiguration) spring.social.twitter.app-id= # your application's Twitter App ID spring.social.twitter.app-secret= # your application's Twitter App Secret # SPRING MOBILE SITE PREFERENCE (SitePreferenceAutoConfiguration) spring.mobile.sitepreference.enabled=true # enabled by default # SPRING MOBILE DEVICE VIEWS (DeviceDelegatingViewResolverAutoConfiguration) spring.mobile.devicedelegatingviewresolver.enabled=true # disabled by default spring.mobile.devicedelegatingviewresolver.enable-fallback= # enable support for fallback resolution, default to false. spring.mobile.devicedelegatingviewresolver.normal-prefix= spring.mobile.devicedelegatingviewresolver.normal-suffix= spring.mobile.devicedelegatingviewresolver.mobile-prefix=mobile/ spring.mobile.devicedelegatingviewresolver.mobile-suffix= spring.mobile.devicedelegatingviewresolver.tablet-prefix=tablet/ spring.mobile.devicedelegatingviewresolver.tablet-suffix= # ---------------------------------------- # DEVTOOLS PROPERTIES # ---------------------------------------- # DEVTOOLS (DevToolsProperties) spring.devtools.restart.enabled=true # enable automatic restart spring.devtools.restart.exclude= # patterns that should be excluding for triggering a full restart spring.devtools.restart.poll-interval= # amount of time (in milliseconds) to wait between polling for classpath changes spring.devtools.restart.quiet-period= # amount of quiet time (in milliseconds) required without any classpath changes before a restart is triggered spring.devtools.restart.trigger-file= # name of a specific file that when changed will trigger the restart spring.devtools.livereload.enabled=true # enable a livereload.com compatible server spring.devtools.livereload.port=35729 # server port. # REMOTE DEVTOOLS (RemoteDevToolsProperties) spring.devtools.remote.context-path=/.~~spring-boot!~ # context path used to handle the remote connection spring.devtools.remote.debug.enabled=true # enable remote debug support spring.devtools.remote.debug.local-port=8000 # local remote debug server port spring.devtools.remote.restart.enabled=true # enable remote restart spring.devtools.remote.secret= # a shared secret required to establish a connection spring.devtools.remote.secret-header-name=X-AUTH-TOKEN # HTTP header used to transfer the shared secret # ---------------------------------------- # ACTUATOR PROPERTIES # ---------------------------------------- # MANAGEMENT HTTP SERVER (ManagementServerProperties) management.port= # defaults to 'server.port' management.address= # bind to a specific NIC management.context-path= # default to '/' management.add-application-context-header= # default to true management.security.enabled=true # enable security management.security.role=ADMIN # role required to access the management endpoint management.security.sessions=stateless # session creating policy to use (always, never, if_required, stateless) # PID FILE (ApplicationPidFileWriter) spring.pid.file= # Location of the PID file to write spring.pid.fail-on-write-error= # Fail if the PID file cannot be written # ENDPOINTS (AbstractEndpoint subclasses) endpoints.autoconfig.id=autoconfig endpoints.autoconfig.sensitive=true endpoints.autoconfig.enabled=true endpoints.beans.id=beans endpoints.beans.sensitive=true endpoints.beans.enabled=true endpoints.configprops.id=configprops endpoints.configprops.sensitive=true endpoints.configprops.enabled=true endpoints.configprops.keys-to-sanitize=password,secret,key,.*credentials.*,vcap_services # suffix or regex endpoints.dump.id=dump endpoints.dump.sensitive=true endpoints.dump.enabled=true endpoints.enabled=true # enable all endpoints endpoints.env.id=env endpoints.env.sensitive=true endpoints.env.enabled=true endpoints.env.keys-to-sanitize=password,secret,key,.*credentials.*,vcap_services # suffix or regex endpoints.health.id=health endpoints.health.sensitive=true endpoints.health.enabled=true endpoints.health.mapping.*= # mapping of health statuses to HttpStatus codes endpoints.health.time-to-live=1000 endpoints.info.id=info endpoints.info.sensitive=false endpoints.info.enabled=true endpoints.logfile.path=/logfile endpoints.logfile.sensitive=true endpoints.logfile.enabled=true endpoints.mappings.enabled=true endpoints.mappings.id=mappings endpoints.mappings.sensitive=true endpoints.metrics.id=metrics endpoints.metrics.sensitive=true endpoints.metrics.enabled=true endpoints.shutdown.id=shutdown endpoints.shutdown.sensitive=true endpoints.shutdown.enabled=false endpoints.trace.id=trace endpoints.trace.sensitive=true endpoints.trace.enabled=true # ENDPOINTS CORS CONFIGURATION (MvcEndpointCorsProperties) endpoints.cors.allow-credentials= # set whether user credentials are support. When not set, credentials are not supported. endpoints.cors.allowed-origins= # comma-separated list of origins to allow. * allows all origins. When not set, CORS support is disabled. endpoints.cors.allowed-methods= # comma-separated list of methods to allow. * allows all methods. When not set, defaults to GET. endpoints.cors.allowed-headers= # comma-separated list of headers to allow in a request. * allows all headers. endpoints.cors.exposed-headers= # comma-separated list of headers to include in a response. endpoints.cors.max-age=1800 # how long, in seconds, the response from a pre-flight request can be cached by clients. # HEALTH INDICATORS (previously health.*) management.health.db.enabled=true management.health.elasticsearch.enabled=true management.health.elasticsearch.indices= # comma-separated index names