2014-03-14 04:18:47 +08:00
[[using-boot]]
= Using Spring Boot
[partintro]
--
This section goes into more detail about how you should use Spring Boot. It covers topics
2017-10-25 04:21:47 +08:00
such as build systems, auto-configuration, and how to run your applications. We also cover
2015-04-10 01:57:40 +08:00
some Spring Boot best practices. Although there is nothing particularly special about
2014-04-11 06:52:14 +08:00
Spring Boot (it is just another library that you can consume), there are a few
2017-10-25 04:21:47 +08:00
recommendations that, when followed, make your development process a
2014-03-14 04:18:47 +08:00
little easier.
2017-10-25 04:21:47 +08:00
If you are starting out with Spring Boot, you should probably read the
2014-10-28 18:53:47 +08:00
_<<getting-started.adoc#getting-started, Getting Started>>_ guide before diving into
2014-03-14 04:18:47 +08:00
this section.
--
[[using-boot-build-systems]]
2017-10-25 04:21:47 +08:00
== Build Systems
2015-10-27 17:50:18 +08:00
It is strongly recommended that you choose a build system that supports
2017-10-25 04:21:47 +08:00
<<using-boot-dependency-management,_dependency management_>> and
2015-10-27 17:50:18 +08:00
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
2017-10-25 04:21:47 +08:00
work with other build systems (Ant, for example), but they are not particularly well
2015-10-27 17:50:18 +08:00
supported.
2015-11-04 12:36:20 +08:00
2015-10-27 17:50:18 +08:00
[[using-boot-dependency-management]]
2017-10-25 04:21:47 +08:00
=== Dependency Management
Each release of Spring Boot provides a curated list of dependencies that it supports. In
2015-10-27 17:50:18 +08:00
practice, you do not need to provide a version for any of these dependencies in your
2017-10-25 04:21:47 +08:00
build configuration, as Spring Boot is managing that for you. When you upgrade Spring
Boot itself, these dependencies are upgraded as well in a consistent way.
2014-03-14 04:18:47 +08:00
2015-10-27 17:50:18 +08:00
NOTE: You can still specify a version and override Spring Boot's recommendations if you
2017-10-25 04:21:47 +08:00
need to do so.
2015-10-27 17:50:18 +08:00
The curated list contains all the spring modules that you can use with Spring Boot as
well as a refined list of third party libraries. The list is available as a standard
<<using-boot-maven-without-a-parent,Bills of Materials (`spring-boot-dependencies`)>>
2017-03-15 04:51:23 +08:00
that can be used with both <<using-boot-maven-parent-pom,Maven>> and
2017-06-02 21:46:11 +08:00
<<using-boot-gradle,Gradle>>.
2015-10-27 17:50:18 +08:00
WARNING: Each release of Spring Boot is associated with a base version of the Spring
2017-10-25 04:21:47 +08:00
Framework. We **highly** recommend that you not specify its version.
2014-03-14 04:18:47 +08:00
2015-11-04 12:36:20 +08:00
2014-03-14 04:18:47 +08:00
[[using-boot-maven]]
=== Maven
Maven users can inherit from the `spring-boot-starter-parent` project to obtain sensible
defaults. The parent project provides the following features:
2017-01-25 04:25:54 +08:00
* Java 1.8 as the default compiler level.
2014-03-14 04:18:47 +08:00
* UTF-8 source encoding.
2017-10-25 04:21:47 +08:00
* A <<using-boot-dependency-management,Dependency Management section>>, inherited from
the spring-boot-dependencies pom, that manages the versions of common dependencies. This
dependency management lets you omit <version> tags for those dependencies when used
in your own pom.
2014-03-14 04:18:47 +08:00
* Sensible https://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html[resource filtering].
2015-08-20 20:14:42 +08:00
* Sensible plugin configuration (http://www.mojohaus.org/exec-maven-plugin/[exec plugin],
2017-10-25 04:21:47 +08:00
https://github.com/ktoso/maven-git-commit-id-plugin[Git commit ID], and
2014-03-14 04:18:47 +08:00
http://maven.apache.org/plugins/maven-shade-plugin/[shade]).
2016-01-26 17:53:07 +08:00
* Sensible resource filtering for `application.properties` and `application.yml` including
2017-10-25 04:21:47 +08:00
profile-specific files (for example, `application-foo.properties` and `application-foo.yml`)
2014-03-14 04:18:47 +08:00
2017-10-25 04:21:47 +08:00
Note that, since the `application.properties` and `application.yml` files accept
Spring style placeholders (`${...}`), the Maven filtering is changed to
use `@..@` placeholders. (You can override that by setting a Maven property called
`resource.delimiter`.)
2014-03-14 04:18:47 +08:00
2014-11-07 14:43:31 +08:00
2014-03-14 04:18:47 +08:00
[[using-boot-maven-parent-pom]]
2017-10-25 04:21:47 +08:00
==== Inheriting the Starter Parent
To configure your project to inherit from the `spring-boot-starter-parent` set
the `parent`, as follows:
2014-03-14 04:18:47 +08:00
[source,xml,indent=0,subs="verbatim,quotes,attributes"]
----
<!-- Inherit defaults from Spring Boot -->
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>{spring-boot-version}</version>
</parent>
----
2017-10-25 04:21:47 +08:00
NOTE: You should need to specify only the Spring Boot version number on this dependency.
2014-04-11 06:52:14 +08:00
If you import additional starters, you can safely omit the version number.
2014-03-14 04:18:47 +08:00
2015-10-27 17:50:18 +08:00
With that setup, you can also override individual dependencies by overriding a property
2017-10-25 04:21:47 +08:00
in your own project. For instance, to upgrade to another Spring Data release train, you would
add the following to your `pom.xml`:
2015-10-27 17:50:18 +08:00
[source,xml,indent=0,subs="verbatim,quotes,attributes"]
----
<properties>
<spring-data-releasetrain.version>Fowler-SR2</spring-data-releasetrain.version>
</properties>
----
2017-10-12 00:51:04 +08:00
TIP: Check the {github-code}/spring-boot-project/spring-boot-dependencies/pom.xml[`spring-boot-dependencies` pom]
2015-10-27 17:50:18 +08:00
for a list of supported properties.
2014-03-14 04:18:47 +08:00
2015-11-04 12:36:20 +08:00
2014-05-10 02:24:03 +08:00
[[using-boot-maven-without-a-parent]]
2017-10-25 04:21:47 +08:00
==== Using Spring Boot without the Parent POM
2014-06-28 20:34:19 +08:00
Not everyone likes inheriting from the `spring-boot-starter-parent` POM. You may have your
2017-10-25 04:21:47 +08:00
own corporate standard parent that you need to use or you may prefer to explicitly
2014-05-10 02:24:03 +08:00
declare all your Maven configuration.
2017-10-25 04:21:47 +08:00
If you do not want to use the `spring-boot-starter-parent`, you can still keep the benefit
2014-05-10 02:24:03 +08:00
of the dependency management (but not the plugin management) by using a `scope=import`
2017-10-25 04:21:47 +08:00
dependency, as follows:
2014-03-14 04:18:47 +08:00
[source,xml,indent=0,subs="verbatim,quotes,attributes"]
----
<dependencyManagement>
<dependencies>
<dependency>
<!-- Import dependency management from Spring Boot -->
<groupId>org.springframework.boot</groupId>
2014-05-05 21:27:15 +08:00
<artifactId>spring-boot-dependencies</artifactId>
2014-03-14 04:18:47 +08:00
<version>{spring-boot-version}</version>
2014-03-22 11:53:32 +08:00
<type>pom</type>
2014-03-14 04:18:47 +08:00
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
----
2017-10-25 04:21:47 +08:00
The preceding sample setup does not let you override individual dependencies by using a property, as
explained above. To achieve the same result, you need to add an entry in the
2015-10-27 17:50:18 +08:00
`dependencyManagement` of your project **before** the `spring-boot-dependencies`
2017-10-25 04:21:47 +08:00
entry. For instance, to upgrade to another Spring Data release train, you could add the
following element to your `pom.xml`:
2015-10-27 17:50:18 +08:00
[source,xml,indent=0,subs="verbatim,quotes,attributes"]
----
<dependencyManagement>
<dependencies>
<!-- Override Spring Data release train provided by Spring Boot -->
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-releasetrain</artifactId>
<version>Fowler-SR2</version>
<scope>import</scope>
<type>pom</type>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-dependencies</artifactId>
<version>{spring-boot-version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
----
2017-10-25 04:21:47 +08:00
NOTE: In the preceding example, we specify a _BOM_, but any dependency type can be overridden
in the same way.
2014-03-14 04:18:47 +08:00
2015-11-04 12:36:20 +08:00
2014-03-14 04:18:47 +08:00
[[using-boot-maven-plugin]]
2017-10-25 04:21:47 +08:00
==== Using the Spring Boot Maven Plugin
2014-03-14 04:18:47 +08:00
Spring Boot includes a <<build-tool-plugins.adoc#build-tool-plugins-maven-plugin, Maven plugin>>
that can package the project as an executable jar. Add the plugin to your `<plugins>`
2017-10-25 04:21:47 +08:00
section if you want to use it, as shown in the following example:
2014-03-14 04:18:47 +08:00
[source,xml,indent=0,subs="verbatim,quotes,attributes"]
----
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
----
2017-10-25 04:21:47 +08:00
NOTE: If you use the Spring Boot starter parent pom, you need to add only the plugin.
There is no need to configure it unless you want to change the settings defined in
2014-06-21 01:25:38 +08:00
the parent.
2014-03-14 04:18:47 +08:00
[[using-boot-gradle]]
=== Gradle
2017-06-02 21:46:11 +08:00
To learn about using Spring Boot with Gradle, please refer to the documentation for
Spring Boot's Gradle plugin:
2014-03-14 04:18:47 +08:00
2017-06-02 21:46:11 +08:00
* Reference ({spring-boot-gradle-plugin}/reference/html[HTML] and
{spring-boot-gradle-plugin}/reference/pdf/spring-boot-gradle-plugin-reference.pdf[PDF])
* {spring-boot-gradle-plugin}/api[API]
2014-03-14 04:18:47 +08:00
[[using-boot-ant]]
=== Ant
2015-06-27 06:09:59 +08:00
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.
2014-03-14 04:18:47 +08:00
2017-10-25 04:21:47 +08:00
To declare dependencies, a typical `ivy.xml` file looks something like the following example:
2015-06-27 06:09:59 +08:00
[source,xml,indent=0]
----
<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>
----
2017-10-25 04:21:47 +08:00
A typical `build.xml` looks like the following example:
2015-06-27 06:09:59 +08:00
2017-10-26 03:29:27 +08:00
[source,xml,indent=0,subs="verbatim,quotes,attributes"]
2015-06-27 06:09:59 +08:00
----
<project
xmlns:ivy="antlib:org.apache.ivy.ant"
xmlns:spring-boot="antlib:org.springframework.boot.ant"
name="myapp" default="build">
2017-10-26 03:29:27 +08:00
<property name="spring-boot.version" value="{spring-boot-version}" />
2015-06-27 06:09:59 +08:00
<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>
----
2017-10-25 04:21:47 +08:00
TIP: If you do not want to use the `spring-boot-antlib` module, see the
_<<howto.adoc#howto-build-an-executable-archive-with-ant>>_ "`How-to`" .
2014-03-14 04:18:47 +08:00
2016-05-18 14:55:42 +08:00
[[using-boot-starter]]
=== Starters
Starters are a set of convenient dependency descriptors that you can include in your
2017-10-25 04:21:47 +08:00
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
2014-03-14 04:18:47 +08:00
descriptors. For example, if you want to get started using Spring and JPA for database
2017-10-25 04:21:47 +08:00
access, include the `spring-boot-starter-data-jpa` dependency in your project.
2014-03-14 04:18:47 +08:00
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.
.What's in a name
****
2015-04-03 16:24:11 +08:00
All **official** starters follow a similar naming pattern; `+spring-boot-starter-*+`,
where `+*+` is a particular type of application. This naming structure is intended to
help when you need to find a starter. The Maven integration in many IDEs allow you to
search dependencies by name. For example, with the appropriate Eclipse or STS plugin
installed, you can simply hit `ctrl-space` in the POM editor and type
2015-06-06 06:42:41 +08:00
"`spring-boot-starter`" for a complete list.
2015-04-03 16:24:11 +08:00
2017-10-25 04:21:47 +08:00
As explained in the <<spring-boot-features#boot-features-custom-starter,Creating Your Own Starter>>
section, third party starters should not start with `spring-boot`, as it is reserved for
official Spring Boot artifacts. Rather, a third-party starter typically starts with the
name of the project. For example, a third-party starter project called `thirdpartyproject`
would typically be named `thirdpartyproject-spring-boot-starter`.
2014-03-14 04:18:47 +08:00
****
The following application starters are provided by Spring Boot under the
`org.springframework.boot` group:
.Spring Boot application starters
2016-03-30 00:19:29 +08:00
include::../../../target/generated-resources/application-starters.adoc[]
2014-03-14 04:18:47 +08:00
2016-03-30 00:19:29 +08:00
In addition to the application starters, the following starters can be used to add
2016-04-01 21:05:25 +08:00
_<<production-ready-features.adoc#production-ready, production ready>>_ features:
2014-03-14 04:18:47 +08:00
2016-03-30 00:19:29 +08:00
.Spring Boot production starters
include::../../../target/generated-resources/production-starters.adoc[]
2014-10-24 19:58:15 +08:00
2017-10-25 04:21:47 +08:00
Finally, Spring Boot also includes the following starters that can be used if you want to exclude
2016-03-30 00:19:29 +08:00
or swap specific technical facets:
2014-03-14 04:18:47 +08:00
.Spring Boot technical starters
2016-03-30 00:19:29 +08:00
include::../../../target/generated-resources/technical-starters.adoc[]
2014-03-14 04:18:47 +08:00
2016-05-18 14:55:42 +08:00
TIP: For a list of additional community contributed starters, see the
2017-10-12 00:51:04 +08:00
{github-master-code}/spring-boot-project/spring-boot-starters/README.adoc[README file] in the
2014-03-25 02:21:36 +08:00
`spring-boot-starters` module on GitHub.
2014-03-14 04:18:47 +08:00
[[using-boot-structuring-your-code]]
2017-10-25 04:21:47 +08:00
== Structuring Your Code
Spring Boot does not require any specific code layout to work. However, there are some
2014-03-14 04:18:47 +08:00
best practices that help.
[[using-boot-using-the-default-package]]
2017-10-25 04:21:47 +08:00
=== Using the "`default`" Package
When a class does not include a `package` declaration, it is considered to be in the
"`default package`". The use of the "`default package`" is generally discouraged and
2014-03-14 04:18:47 +08:00
should be avoided. It can cause particular problems for Spring Boot applications that
2017-10-25 04:21:47 +08:00
use the `@ComponentScan`, `@EntityScan`, or `@SpringBootApplication` annotations, since every
class from every jar is read.
2014-03-14 04:18:47 +08:00
2014-03-18 02:36:56 +08:00
TIP: We recommend that you follow Java's recommended package naming conventions
2014-03-14 04:18:47 +08:00
and use a reversed domain name (for example, `com.example.project`).
[[using-boot-locating-the-main-class]]
2017-10-25 04:21:47 +08:00
=== Locating the Main Application Class
2014-03-14 04:18:47 +08:00
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
2014-10-28 18:53:47 +08:00
main class, and it implicitly defines a base "`search package`" for certain items. For
2014-03-14 04:18:47 +08:00
example, if you are writing a JPA application, the package of the
2017-10-25 04:21:47 +08:00
`@EnableAutoConfiguration` annotated class is used to search for `@Entity` items.
2014-03-14 04:18:47 +08:00
2017-10-25 04:21:47 +08:00
Using a root package also lets the `@ComponentScan` annotation be used without
2014-12-10 11:52:56 +08:00
needing to specify a `basePackage` attribute. You can also use the
`@SpringBootApplication` annotation if your main class is in the root package.
2014-03-14 04:18:47 +08:00
2017-10-25 04:21:47 +08:00
The following listing shows a typical layout:
2014-03-14 04:18:47 +08:00
[indent=0]
----
com
+- example
2017-07-30 04:10:19 +08:00
+- myapplication
2014-03-14 04:18:47 +08:00
+- Application.java
|
2017-07-30 04:10:19 +08:00
+- customer
2014-03-14 04:18:47 +08:00
| +- Customer.java
2017-07-30 04:10:19 +08:00
| +- CustomerController.java
2014-03-14 04:18:47 +08:00
| +- CustomerService.java
2017-07-30 04:10:19 +08:00
| +- CustomerRepository.java
2014-03-14 04:18:47 +08:00
|
2017-07-30 04:10:19 +08:00
+- order
+- Order.java
+- OrderController.java
+- OrderService.java
+- OrderRepository.java
2014-03-14 04:18:47 +08:00
----
The `Application.java` file would declare the `main` method, along with the basic
2017-10-25 04:21:47 +08:00
`@Configuration`, as follows:
2014-03-14 04:18:47 +08:00
[source,java,indent=0]
----
2017-09-18 22:13:59 +08:00
package com.example.myapplication;
2014-03-14 04:18:47 +08:00
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);
}
}
----
[[using-boot-configuration-classes]]
2017-10-25 04:21:47 +08:00
== Configuration Classes
2017-05-16 09:21:34 +08:00
Spring Boot favors Java-based configuration. Although it is possible to use
2017-10-25 04:21:47 +08:00
`SpringApplication` with XML sources, we generally recommend that your primary
source be a single `@Configuration` class. Usually the class that defines the `main`
method is a good candidate as the primary `@Configuration`.
2014-03-14 04:18:47 +08:00
TIP: Many Spring configuration examples have been published on the Internet that use XML
2017-10-25 04:21:47 +08:00
configuration. If possible, always try to use the equivalent Java-based configuration.
2017-03-10 16:22:00 +08:00
Searching for `+Enable*+` annotations can be a good starting point.
2014-03-14 04:18:47 +08:00
[[using-boot-importing-configuration]]
2017-10-25 04:21:47 +08:00
=== Importing Additional Configuration Classes
You need not put all your `@Configuration` into a single class. The `@Import`
2014-03-14 04:18:47 +08:00
annotation can be used to import additional configuration classes. Alternatively, you
2015-10-05 01:59:38 +08:00
can use `@ComponentScan` to automatically pick up all Spring components, including
2014-03-14 04:18:47 +08:00
`@Configuration` classes.
[[using-boot-importing-xml-configuration]]
2017-10-25 04:21:47 +08:00
=== Importing XML Configuration
2014-03-14 04:18:47 +08:00
If you absolutely must use XML based configuration, we recommend that you still start
2017-10-25 04:21:47 +08:00
with a `@Configuration` class. You can then use an `@ImportResource`
2014-03-14 04:18:47 +08:00
annotation to load XML configuration files.
[[using-boot-auto-configuration]]
== Auto-configuration
Spring Boot auto-configuration attempts to automatically configure your Spring
2017-09-15 22:02:35 +08:00
application based on the jar dependencies that you have added. For example, if
2014-03-14 04:18:47 +08:00
`HSQLDB` is on your classpath, and you have not manually configured any database
2017-10-25 04:21:47 +08:00
connection beans, then Spring Boot auto-configures an in-memory database.
2014-03-14 04:18:47 +08:00
2014-12-10 11:52:56 +08:00
You need to opt-in to auto-configuration by adding the `@EnableAutoConfiguration` or
`@SpringBootApplication` annotations to one of your `@Configuration` classes.
2014-03-14 04:18:47 +08:00
TIP: You should only ever add one `@EnableAutoConfiguration` annotation. We generally
recommend that you add it to your primary `@Configuration` class.
[[using-boot-replacing-auto-configuration]]
2017-10-25 04:21:47 +08:00
=== Gradually Replacing Auto-configuration
Auto-configuration is noninvasive. At any point, you can start to define your own
2014-03-14 04:18:47 +08:00
configuration to replace specific parts of the auto-configuration. For example, if
2017-10-25 04:21:47 +08:00
you add your own `DataSource` bean, the default embedded database support backs away.
2014-03-14 04:18:47 +08:00
If you need to find out what auto-configuration is currently being applied, and why,
2017-10-25 04:21:47 +08:00
start your application with the `--debug` switch. Doing so enables debug logs for a
selection of core loggers and logs an auto-configuration report to the console.
2014-03-14 04:18:47 +08:00
2015-08-03 21:55:05 +08:00
[[using-boot-disabling-specific-auto-configuration]]
2017-10-25 04:21:47 +08:00
=== Disabling Specific Auto-configuration Classes
If you find that specific auto-configuration classes that you do not want are being applied,
you can use the exclude attribute of `@EnableAutoConfiguration` to disable them, as shown
in the following example:
2014-03-14 04:18:47 +08:00
[source,java,indent=0]
----
import org.springframework.boot.autoconfigure.*;
import org.springframework.boot.autoconfigure.jdbc.*;
import org.springframework.context.annotation.*;
@Configuration
2014-05-06 21:05:39 +08:00
@EnableAutoConfiguration(exclude={DataSourceAutoConfiguration.class})
2014-03-14 04:18:47 +08:00
public class MyConfiguration {
}
----
2015-08-03 21:55:05 +08:00
If the class is not on the classpath, you can use the `excludeName` attribute of
the annotation and specify the fully qualified name instead. Finally, you can also
2017-10-25 04:21:47 +08:00
control the list of auto-configuration classes to exclude by using the
2015-08-03 21:55:05 +08:00
`spring.autoconfigure.exclude` property.
2014-03-14 04:18:47 +08:00
2017-10-25 04:21:47 +08:00
TIP: You can define exclusions both at the annotation level and by using the property.
2014-03-14 04:18:47 +08:00
[[using-boot-spring-beans-and-dependency-injection]]
2017-10-25 04:21:47 +08:00
== Spring Beans and Dependency Injection
2014-03-18 02:36:56 +08:00
You are free to use any of the standard Spring Framework techniques to define your beans
2014-03-14 04:18:47 +08:00
and their injected dependencies. For simplicity, we often find that using `@ComponentScan`
2017-10-25 04:21:47 +08:00
(to find your beans) and using `@Autowired` (to do constructor injection) works well.
2014-03-14 04:18:47 +08:00
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
2017-10-25 04:21:47 +08:00
components (`@Component`, `@Service`, `@Repository`, `@Controller` etc.) are
2014-03-14 04:18:47 +08:00
automatically registered as Spring Beans.
2017-10-25 04:21:47 +08:00
The following example shows a `@Service` Bean that uses constructor injection to obtain a
required `RiskAssessor` bean:
2014-03-14 04:18:47 +08:00
[source,java,indent=0]
----
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;
}
// ...
}
----
2017-10-25 04:21:47 +08:00
If a bean has one constructor, you can omit the `@Autowired`, as shown in the following
example:
2017-02-24 11:04:29 +08:00
[source,java,indent=0]
----
@Service
public class DatabaseAccountService implements AccountService {
private final RiskAssessor riskAssessor;
public DatabaseAccountService(RiskAssessor riskAssessor) {
this.riskAssessor = riskAssessor;
}
// ...
}
----
2017-10-25 04:21:47 +08:00
TIP: Notice how using constructor injection lets the `riskAssessor` field be marked
2014-03-14 04:18:47 +08:00
as `final`, indicating that it cannot be subsequently changed.
2014-11-07 14:43:31 +08:00
2014-11-07 14:46:09 +08:00
[[using-boot-using-springbootapplication-annotation]]
2017-10-25 04:21:47 +08:00
== Using the @SpringBootApplication Annotation
2014-11-07 14:46:09 +08:00
Many Spring Boot developers always have their main class annotated with `@Configuration`,
2017-10-25 04:21:47 +08:00
`@EnableAutoConfiguration`, and `@ComponentScan`. Since these annotations are so frequently
2014-11-07 14:46:09 +08:00
used together (especially if you follow the <<using-boot-structuring-your-code, best practices>>
above), Spring Boot provides a convenient `@SpringBootApplication` alternative.
The `@SpringBootApplication` annotation is equivalent to using `@Configuration`,
2017-10-25 04:21:47 +08:00
`@EnableAutoConfiguration`, and `@ComponentScan` with their default attributes, as shown
in the following example:
2014-11-07 14:46:09 +08:00
[source,java,indent=0]
----
2017-09-18 22:13:59 +08:00
package com.example.myapplication;
2014-11-07 14:46:09 +08:00
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);
}
}
----
2015-08-27 20:12:01 +08:00
NOTE: `@SpringBootApplication` also provides aliases to customize the attributes of
`@EnableAutoConfiguration` and `@ComponentScan`.
2014-11-07 14:46:09 +08:00
2014-03-14 04:18:47 +08:00
[[using-boot-running-your-application]]
2017-10-25 04:21:47 +08:00
== Running Your Application
One of the biggest advantages of packaging your application as a jar and using an embedded
2014-03-14 04:18:47 +08:00
HTTP server is that you can run your application as you would any other. Debugging Spring
2017-10-25 04:21:47 +08:00
Boot applications is also easy. You do not need any special IDE plugins or extensions.
2014-03-14 04:18:47 +08:00
2017-10-25 04:21:47 +08:00
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.
2014-03-14 04:18:47 +08:00
[[using-boot-running-from-an-ide]]
=== Running from an IDE
2017-10-25 04:21:47 +08:00
You can run a Spring Boot application from your IDE as a simple Java application. However,
you first need to import your project. Import steps vary depending on your IDE
and build system. Most IDEs can import Maven projects directly. For example, Eclipse users
2014-03-14 04:18:47 +08:00
can select `Import...` -> `Existing Maven Projects` from the `File` menu.
2017-10-25 04:21:47 +08:00
If you cannot directly import your project into your IDE, you may be able to generate IDE
metadata by using a build plugin. Maven includes plugins for
2014-03-14 04:18:47 +08:00
http://maven.apache.org/plugins/maven-eclipse-plugin/[Eclipse] and
2017-10-25 04:21:47 +08:00
http://maven.apache.org/plugins/maven-idea-plugin/[IDEA]. Gradle offers plugins
2016-09-15 21:01:53 +08:00
for {gradle-user-guide}/userguide.html[various IDEs].
2014-03-14 04:18:47 +08:00
2017-10-25 04:21:47 +08:00
TIP: If you accidentally run a web application twice, you see a "`Port already in
use`" error. STS users can use the `Relaunch` button rather than the `Run` button to ensure that
2014-03-14 04:18:47 +08:00
any existing instance is closed.
[[using-boot-running-as-a-packaged-application]]
2017-10-25 04:21:47 +08:00
=== Running as a Packaged Application
If you use the Spring Boot Maven or Gradle plugins to create an executable jar, you can
run your application using `java -jar`, as shown in the following example:
2014-03-14 04:18:47 +08:00
[indent=0,subs="attributes"]
----
2017-09-18 22:13:59 +08:00
$ java -jar target/myapplication-0.0.1-SNAPSHOT.jar
2014-03-14 04:18:47 +08:00
----
It is also possible to run a packaged application with remote debugging support enabled.
2017-10-25 04:21:47 +08:00
Doing so lets you attach a debugger to your packaged application, as shown in the following example:
2014-03-14 04:18:47 +08:00
[indent=0,subs="attributes"]
----
$ java -Xdebug -Xrunjdwp:server=y,transport=dt_socket,address=8000,suspend=n \
2017-09-18 22:13:59 +08:00
-jar target/myapplication-0.0.1-SNAPSHOT.jar
2014-03-14 04:18:47 +08:00
----
2014-05-29 00:35:15 +08:00
2014-03-14 04:18:47 +08:00
[[using-boot-running-with-the-maven-plugin]]
2017-10-25 04:21:47 +08:00
=== Using the Maven Plugin
The Spring Boot Maven plugin includes a `run` goal that can be used to quickly compile
and run your application. Applications run in an exploded form, as they do in your IDE.
2014-03-14 04:18:47 +08:00
[indent=0,subs="attributes"]
----
$ mvn spring-boot:run
----
2017-10-25 04:21:47 +08:00
You might also want to use the `MAVEN_OPTS` operating system environment variable, as shown in the following example:
2014-03-14 04:18:47 +08:00
2014-05-29 00:35:15 +08:00
[indent=0,subs="attributes"]
----
2017-01-25 04:25:54 +08:00
$ export MAVEN_OPTS=-Xmx1024m
2014-05-29 00:35:15 +08:00
----
2014-05-28 19:10:57 +08:00
2014-06-10 07:28:30 +08:00
2014-03-14 04:18:47 +08:00
[[using-boot-running-with-the-gradle-plugin]]
2017-10-25 04:21:47 +08:00
=== Using the Gradle Plugin
The Spring Boot Gradle plugin also includes a `bootRun` task that can be used to run
2017-03-15 04:51:23 +08:00
your application in an exploded form. The `bootRun` task is added whenever you apply the
2017-10-25 04:21:47 +08:00
the `org.springframework.boot` and `java` plugins and is shown in the following example:
2014-03-14 04:18:47 +08:00
[indent=0,subs="attributes"]
----
$ gradle bootRun
----
2017-10-25 04:21:47 +08:00
You might also want to use the `JAVA_OPTS` operating system environment variable, as shown in the following example:
2014-05-28 19:10:57 +08:00
2014-05-29 00:35:15 +08:00
[indent=0,subs="attributes"]
----
2017-01-25 04:25:54 +08:00
$ export JAVA_OPTS=-Xmx1024m
2014-05-29 00:35:15 +08:00
----
2014-03-14 04:18:47 +08:00
[[using-boot-hot-swapping]]
2017-10-25 04:21:47 +08:00
=== Hot Swapping
2014-04-11 06:52:14 +08:00
Since Spring Boot applications are just plain Java applications, JVM hot-swapping should
2014-03-14 04:18:47 +08:00
work out of the box. JVM hot swapping is somewhat limited with the bytecode that it can
2017-10-25 04:21:47 +08:00
replace. For a more complete solution,
http://zeroturnaround.com/software/jrebel/[JRebel] can be used.
2014-03-14 04:18:47 +08:00
2017-10-25 04:21:47 +08:00
The
`spring-boot-devtools` module also includes support for quick application restarts.
2015-06-11 13:06:19 +08:00
See the <<using-boot-devtools>> section below and the
<<howto.adoc#howto-hotswapping, Hot swapping "`How-to`">> for details.
[[using-boot-devtools]]
2017-10-25 04:21:47 +08:00
== Developer Tools
2015-06-11 13:06:19 +08:00
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
2017-10-25 04:21:47 +08:00
devtools support, add the module dependency to your build, as shown in the following listings for Maven and Gradle:
2015-06-11 13:06:19 +08:00
.Maven
[source,xml,indent=0,subs="verbatim,quotes,attributes"]
----
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-devtools</artifactId>
2015-08-04 23:36:27 +08:00
<optional>true</optional>
2015-06-11 13:06:19 +08:00
</dependency>
</dependencies>
----
.Gradle
[source,groovy,indent=0,subs="attributes"]
----
dependencies {
compile("org.springframework.boot:spring-boot-devtools")
}
----
NOTE: Developer tools are automatically disabled when running a fully packaged
2017-10-25 04:21:47 +08:00
application. If your application is launched using `java -jar` or if it is started from a
2015-08-04 23:36:27 +08:00
special classloader, then it is considered a "`production application`". Flagging the
dependency as optional is a best practice that prevents devtools from being transitively
applied to other modules using your project. Gradle does not support `optional`
2017-10-25 04:21:47 +08:00
dependencies out-of-the-box, so you may want to have a look at the
{propdeps-plugin}[`propdeps-plugin`].
2015-06-11 13:06:19 +08:00
2017-10-25 04:21:47 +08:00
TIP: Repackaged archives do not contain devtools by default. If you want to use a
<<using-boot-devtools-remote,certain remote devtools feature>>, you need to disable the
2016-11-03 19:27:30 +08:00
`excludeDevtools` build property to include it. The property is supported with both the
Maven and Gradle plugins.
2015-10-13 22:59:35 +08:00
2015-06-11 13:06:19 +08:00
[[using-boot-devtools-property-defaults]]
2017-10-25 04:21:47 +08:00
=== Property Defaults
2015-06-11 13:06:19 +08:00
Several of the libraries supported by Spring Boot use caches to improve performance. For
2016-12-16 00:14:19 +08:00
example, <<spring-boot-features#boot-features-spring-mvc-template-engines,template engines>>
2017-10-25 04:21:47 +08:00
cache compiled templates to avoid repeatedly parsing template files.
2016-12-16 00:14:19 +08:00
Also, Spring MVC can add HTTP caching headers to responses when serving static resources.
2017-10-25 04:21:47 +08:00
While caching is very beneficial in production, it can be counter-productive during
2016-12-20 02:29:42 +08:00
development, preventing you from seeing the changes you just made in your application.
2017-10-25 04:21:47 +08:00
For this reason, spring-boot-devtools disables the caching options by default.
2015-06-11 13:06:19 +08:00
Cache options are usually configured by settings in your `application.properties` file.
For example, Thymeleaf offers the `spring.thymeleaf.cache` property. Rather than needing
2017-10-25 04:21:47 +08:00
to set these properties manually, the `spring-boot-devtools` module automatically
applies sensible development-time configuration.
2015-06-11 13:06:19 +08:00
2017-10-25 04:21:47 +08:00
TIP: For a complete list of the properties that are applied by the devtools, see
2015-09-08 00:24:42 +08:00
{sc-spring-boot-devtools}/env/DevToolsPropertyDefaultsPostProcessor.{sc-ext}[DevToolsPropertyDefaultsPostProcessor].
2015-06-11 13:06:19 +08:00
[[using-boot-devtools-restart]]
2017-10-25 04:21:47 +08:00
=== Automatic Restart
Applications that use `spring-boot-devtools` automatically restart whenever files
on the classpath change. This can be a useful feature when working in an IDE, as it gives
2015-06-11 13:06:19 +08:00
a very fast feedback loop for code changes. By default, any entry on the classpath that
2017-10-25 04:21:47 +08:00
points to a folder is monitored for changes. Note that certain resources, such as
static assets and view templates, <<using-boot-devtools-restart-exclude, do not need to
2016-02-12 00:52:38 +08:00
restart the application>>.
2015-06-11 13:06:19 +08:00
2015-12-04 22:26:56 +08:00
.Triggering a restart
2015-11-13 16:41:40 +08:00
****
2015-12-07 17:27:37 +08:00
As DevTools monitors classpath resources, the only way to trigger a restart is to update
the classpath. The way in which you cause the classpath to be updated depends on the IDE
2017-10-25 04:21:47 +08:00
that you are using. In Eclipse, saving a modified file causes the classpath to be
updated and triggers a restart. In IntelliJ IDEA, building the project (`Build +->+ Make
2015-12-07 17:27:37 +08:00
Project`) will have the same effect.
2015-11-13 16:41:40 +08:00
****
2015-12-14 22:16:30 +08:00
[NOTE]
====
2017-10-25 04:21:47 +08:00
As long as forking is enabled, you can also start your application by using the supported
build plugins (Maven and Gradle), since DevTools needs an isolated application
classloader to operate properly. By default, Gradle and Maven do that when they detect
2016-11-03 19:29:57 +08:00
DevTools on the classpath.
2015-12-14 22:16:30 +08:00
====
2015-08-04 23:42:53 +08:00
2015-06-28 20:46:30 +08:00
TIP: Automatic restart works very well when used with LiveReload.
2017-10-25 04:21:47 +08:00
<<using-boot-devtools-livereload,See the LiveReload section>> for details. If you use JRebel, automatic
restarts are disabled in favor of dynamic class reloading. Other devtools features
2015-11-13 16:41:40 +08:00
(such as LiveReload and property overrides) can still be used.
2015-10-01 06:39:12 +08:00
2015-10-26 19:04:54 +08:00
NOTE: DevTools relies on the application context's shutdown hook to close it during a
2017-10-25 04:21:47 +08:00
restart. It does not work correctly if you have disabled the shutdown hook
(`SpringApplication.setRegisterShutdownHook(false)`).
2015-10-26 19:04:54 +08:00
2015-12-04 22:34:20 +08:00
NOTE: When deciding if an entry on the classpath should trigger a restart when it changes,
DevTools automatically ignores projects named `spring-boot`, `spring-boot-devtools`,
`spring-boot-autoconfigure`, `spring-boot-actuator`, and `spring-boot-starter`.
2017-10-25 04:21:47 +08:00
NOTE: DevTools needs to customize the `ResourceLoader` used by the `ApplicationContext`.
If your application provides one already, it is going to be wrapped. Direct override of
2017-06-06 22:04:12 +08:00
the `getResource` method on the `ApplicationContext` is not supported.
2015-11-14 13:35:15 +08:00
[[using-spring-boot-restart-vs-reload]]
2015-06-11 13:06:19 +08:00
.Restart vs Reload
****
The restart technology provided by Spring Boot works by using two classloaders.
2017-10-25 04:21:47 +08:00
Classes that do not change (for example, those from third-party jars) are loaded into a
_base_ classloader. Classes that you are actively developing are loaded into a _restart_
2015-06-11 13:06:19 +08:00
classloader. When the application is restarted, the _restart_ classloader is thrown away
and a new one is created. This approach means that application restarts are typically much
2017-10-25 04:21:47 +08:00
faster than "`cold starts`", since the _base_ classloader is already available and
2015-06-11 13:06:19 +08:00
populated.
2017-10-25 04:21:47 +08:00
If you find that restarts are not quick enough for your applications or you encounter
2015-11-14 13:35:15 +08:00
classloading issues, you could consider reloading technologies such as
http://zeroturnaround.com/software/jrebel/[JRebel] from ZeroTurnaround. These work by
rewriting classes as they are loaded to make them more amenable to reloading.
2015-06-11 13:06:19 +08:00
****
2015-08-05 18:44:26 +08:00
[[using-boot-devtools-restart-exclude]]
2017-10-25 04:21:47 +08:00
==== Excluding Resources
Certain resources do not necessarily need to trigger a restart when they are changed. For
example, Thymeleaf templates can be edited in-place. By default, changing resources
in `/META-INF/maven`, `/META-INF/resources`, `/resources`, `/static`, `/public`, or
`/templates` does not trigger a restart but does trigger a
<<using-boot-devtools-livereload, live reload>>. If you want to customize these exclusions,
2015-08-05 18:44:26 +08:00
you can use the `spring.devtools.restart.exclude` property. For example, to exclude only
2017-10-25 04:21:47 +08:00
`/static` and `/public` you would set the following property:
2015-06-11 13:06:19 +08:00
[indent=0]
----
spring.devtools.restart.exclude=static/**,public/**
----
2017-10-25 04:21:47 +08:00
TIP: If you want to keep those defaults and _add_ additional exclusions, use the
2015-09-11 01:35:09 +08:00
`spring.devtools.restart.additional-exclude` property instead.
2015-06-11 13:06:19 +08:00
2015-08-05 18:44:26 +08:00
[[using-boot-devtools-restart-additional-paths]]
2017-10-25 04:21:47 +08:00
==== Watching Additional Paths
2015-08-05 18:44:26 +08:00
You may want your application to be restarted or reloaded when you make changes to files
that are not on the classpath. To do so, use the
`spring.devtools.restart.additional-paths` property to configure additional paths to watch
for changes. You can use the `spring.devtools.restart.exclude` property
<<using-boot-devtools-restart-exclude, described above>> to control whether changes
2017-10-25 04:21:47 +08:00
beneath the additional paths trigger a full restart or a
2015-08-05 18:44:26 +08:00
<<using-boot-devtools-livereload, live reload>>.
2015-06-11 13:06:19 +08:00
[[using-boot-devtools-restart-disable]]
2017-10-25 04:21:47 +08:00
==== Disabling Restart
If you do not want to use the restart feature, you can disable it by using the
`spring.devtools.restart.enabled` property. In most cases, you can set this property in your
`application.properties` (doing so still initializes the restart classloader, but it does not
2015-06-11 13:06:19 +08:00
watch for file changes).
2017-10-25 04:21:47 +08:00
If you need to _completely_ disable restart support (for example, because it doesn't work
with a specific library), you need to set the `spring.devtools.restart.enabled` `System` property to `false` before calling
`SpringApplication.run(...)`, as shown in the following example:
2015-06-11 13:06:19 +08:00
[source,java,indent=0]
----
public static void main(String[] args) {
System.setProperty("spring.devtools.restart.enabled", "false");
SpringApplication.run(MyApp.class, args);
}
----
[[using-boot-devtools-restart-triggerfile]]
2017-10-25 04:21:47 +08:00
==== Using a Trigger File
2015-06-11 13:06:19 +08:00
If you work with an IDE that continuously compiles changed files, you might prefer to
2017-10-25 04:21:47 +08:00
trigger restarts only at specific times. To do so, you can use a "`trigger file`", which
2015-06-11 13:06:19 +08:00
is a special file that must be modified when you want to actually trigger a restart check.
2016-08-10 16:27:10 +08:00
Changing the file only triggers the check and the restart will only occur if Devtools has
2017-10-25 04:21:47 +08:00
detected it has to do something. The trigger file can be updated manually or via an IDE
2016-08-10 16:27:10 +08:00
plugin.
2015-06-11 13:06:19 +08:00
2017-10-25 04:21:47 +08:00
To use a trigger file, set the `spring.devtools.restart.trigger-file` property to the path of your trigger file.
2015-06-11 13:06:19 +08:00
TIP: You might want to set `spring.devtools.restart.trigger-file` as a
2017-10-25 04:21:47 +08:00
<<using-boot-devtools-globalsettings,global setting>>, so that all your projects behave
2015-06-11 13:06:19 +08:00
in the same way.
2015-11-14 13:35:15 +08:00
[[using-boot-devtools-customizing-classload]]
2017-10-25 04:21:47 +08:00
==== Customizing the Restart Classloader
2015-11-14 13:35:15 +08:00
As described in the <<using-spring-boot-restart-vs-reload>> section above, restart
2017-10-25 04:21:47 +08:00
functionality is implemented by using two classloaders. For most applications, this
approach works well. However, sometimes it can cause classloading issues.
2015-11-14 13:35:15 +08:00
2017-10-25 04:21:47 +08:00
By default, any open project in your IDE is loaded with the "`restart`" classloader,
and any regular `.jar` file is loaded with the "`base`" classloader. If you work on
a multi-module project, and not every module is imported into your IDE, you may need to
customize things. To do so, you can create a `META-INF/spring-devtools.properties` file.
2015-11-14 13:35:15 +08:00
2017-10-25 04:21:47 +08:00
The `spring-devtools.properties` file can contain properties prefixed with `restart.exclude` and
`restart.include`. The `include` elements are items that should be
2015-11-21 11:12:05 +08:00
pulled up into the "`restart`" classloader, and the `exclude` elements are items that
2015-11-14 13:35:15 +08:00
should be pushed down into the "`base`" classloader. The value of the property is a regex
2017-10-25 04:21:47 +08:00
pattern that is applied to the classpath, as shown in the following example:
2015-11-14 13:35:15 +08:00
[source,properties,indent=0]
----
2016-09-19 12:58:01 +08:00
restart.exclude.companycommonlibs=/mycorp-common-[\\w-]+\.jar
2015-11-14 13:35:15 +08:00
restart.include.projectcommon=/mycorp-myproj-[\\w-]+\.jar
----
NOTE: All property keys must be unique. As long as a property starts with
2017-10-25 04:21:47 +08:00
`restart.include.` or `restart.exclude.` it is considered.
2015-11-14 13:35:15 +08:00
TIP: All `META-INF/spring-devtools.properties` from the classpath will be loaded. You can
package files inside your project, or in the libraries that the project consumes.
[[using-boot-devtools-known-restart-limitations]]
2017-10-25 04:21:47 +08:00
==== Known Limitations
Restart functionality does not work well with objects that are deserialized by using a
2015-11-14 13:35:15 +08:00
standard `ObjectInputStream`. If you need to deserialize data, you may need to use Spring's
`ConfigurableObjectInputStream` in combination with
`Thread.currentThread().getContextClassLoader()`.
Unfortunately, several third-party libraries deserialize without considering the context
2017-10-25 04:21:47 +08:00
classloader. If you find such a problem, you need to request a fix with the original
2015-11-14 13:35:15 +08:00
authors.
2015-06-11 13:06:19 +08:00
[[using-boot-devtools-livereload]]
=== LiveReload
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
http://livereload.com/extensions/[livereload.com].
2017-10-25 04:21:47 +08:00
If you do not want to start the LiveReload server when your application runs, you can set
2015-06-11 13:06:19 +08:00
the `spring.devtools.livereload.enabled` property to `false`.
2016-10-07 20:21:00 +08:00
NOTE: You can only run one LiveReload server at a time. Before starting your application,
ensure that no other LiveReload servers are running. If you start multiple applications
2017-10-25 04:21:47 +08:00
from your IDE, only the first has LiveReload support.
2015-06-11 13:06:19 +08:00
[[using-boot-devtools-globalsettings]]
2017-10-25 04:21:47 +08:00
=== Global Settings
2015-06-11 13:06:19 +08:00
You can configure global devtools settings by adding a file named
`.spring-boot-devtools.properties` to your `$HOME` folder (note that the filename starts
2017-10-25 04:21:47 +08:00
with "`.`"). Any properties added to this file apply to _all_ Spring Boot
2015-06-11 13:06:19 +08:00
applications on your machine that use devtools. For example, to configure restart to
always use a <<using-boot-devtools-restart-triggerfile, trigger file>>, you would add
2017-10-25 04:21:47 +08:00
the following property:
2015-06-11 13:06:19 +08:00
.~/.spring-boot-devtools.properties
[source,properties,indent=0]
----
spring.devtools.reload.trigger-file=.reloadtrigger
----
[[using-boot-devtools-remote]]
2017-10-25 04:21:47 +08:00
=== Remote Applications
2015-06-11 13:06:19 +08:00
The Spring Boot developer tools are not just limited to local development. You can also
2017-10-25 04:21:47 +08:00
use several features when running applications remotely. Remote support is opt-in. To
enable it, you need to make sure that `devtools` is included in the repackaged archive, as shown in the following listing:
2016-11-03 19:27:30 +08:00
[source,xml,indent=0,subs="verbatim,quotes,attributes"]
----
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<excludeDevtools>false</excludeDevtools>
</configuration>
</plugin>
</plugins>
</build>
----
2017-10-25 04:21:47 +08:00
Then you need to set a `spring.devtools.remote.secret` property, as shown in the following example:
2015-06-11 13:06:19 +08:00
[source,properties,indent=0]
----
2015-06-15 17:29:38 +08:00
spring.devtools.remote.secret=mysecret
2015-06-11 13:06:19 +08:00
----
WARNING: Enabling `spring-boot-devtools` on a remote application is a security risk. You
should never enable support on a production deployment.
2017-10-25 04:21:47 +08:00
Remote devtools support is provided in two parts: a server-side endpoint that
accepts connections and a client application that you run in your IDE. The server
2015-06-15 17:29:38 +08:00
component is automatically enabled when the `spring.devtools.remote.secret` property
2015-06-11 13:06:19 +08:00
is set. The client component must be launched manually.
2017-10-25 04:21:47 +08:00
==== Running the Remote Client Application
2016-12-28 04:16:27 +08:00
The remote client application is designed to be run from within your IDE. You need to run
2017-10-25 04:21:47 +08:00
`org.springframework.boot.devtools.RemoteSpringApplication` with the same classpath as
the remote project that you connect to.
The application's single required argument is the remote URL to which it connects.
2015-06-11 13:06:19 +08:00
2017-10-25 04:21:47 +08:00
For example, if you are using Eclipse or STS and you have a project named `my-app` that
you have deployed to Cloud Foundry, you would do the following:
2015-06-11 13:06:19 +08:00
* Select `Run Configurations...` from the `Run` menu.
* Create a new `Java Application` "`launch configuration`".
* Browse for the `my-app` project.
* Use `org.springframework.boot.devtools.RemoteSpringApplication` as the main class.
2015-06-11 15:33:09 +08:00
* Add `+++https://myapp.cfapps.io+++` to the `Program arguments` (or whatever your remote
2015-06-11 13:06:19 +08:00
URL is).
2017-10-25 04:21:47 +08:00
A running remote client might resemble the following listing:
2015-06-11 13:06:19 +08:00
[indent=0,subs="attributes"]
----
. ____ _ __ _ _
/\\ / ___'_ __ _ _(_)_ __ __ _ ___ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | | _ \___ _ __ ___| |_ ___ \ \ \ \
\\/ ___)| |_)| | | | | || (_| []::::::[] / -_) ' \/ _ \ _/ -_) ) ) ) )
' |____| .__|_| |_|_| |_\__, | |_|_\___|_|_|_\___/\__\___|/ / / /
=========|_|==============|___/===================================/_/_/_/
:: Spring Boot Remote :: {spring-boot-version}
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
2015-06-15 17:29:38 +08:00
can directly read application properties. This is how the `spring.devtools.remote.secret`
2015-06-11 13:06:19 +08:00
property is read and passed to the server for authentication.
2017-10-25 04:21:47 +08:00
TIP: It is always advisable to use `https://` as the connection protocol, so that traffic is
2015-06-11 13:06:19 +08:00
encrypted and passwords cannot be intercepted.
2015-10-02 17:28:57 +08:00
TIP: If you need to use a proxy to access the remote application, configure the
`spring.devtools.remote.proxy.host` and `spring.devtools.remote.proxy.port` properties.
2015-06-11 13:06:19 +08:00
[[using-boot-devtools-remote-update]]
2017-10-25 04:21:47 +08:00
==== Remote Update
The remote client monitors your application classpath for changes in the same way as
the <<using-boot-devtools-restart,local restart>>. Any updated resource is pushed
to the remote application and (_if required_) triggers a restart. This can be helpful
if you iterate on a feature that uses a cloud service that you do not have locally.
Generally, remote updates and restarts are much quicker than a full rebuild and deploy
2015-06-11 13:06:19 +08:00
cycle.
NOTE: Files are only monitored when the remote client is running. If you change a file
2017-10-25 04:21:47 +08:00
before starting the remote client, it is not pushed to the remote server.
2015-06-11 13:06:19 +08:00
2014-03-14 04:18:47 +08:00
[[using-boot-packaging-for-production]]
2017-10-25 04:21:47 +08:00
== Packaging Your Application for Production
2014-10-13 03:47:19 +08:00
Executable jars can be used for production deployment. As they are self-contained, they
2014-03-14 04:18:47 +08:00
are also ideally suited for cloud-based deployment.
2017-10-25 04:21:47 +08:00
For additional "`production ready`" features, such as health, auditing, and metric REST
or JMX end-points, consider adding `spring-boot-actuator`. See
2014-10-28 18:53:47 +08:00
_<<production-ready-features.adoc#production-ready>>_ for details.
2014-03-14 04:18:47 +08:00
[[using-boot-whats-next]]
2017-10-25 04:21:47 +08:00
== What to Read Next
You should now understand how you can use Spring Boot and some best
2014-03-14 04:18:47 +08:00
practices that you should follow. You can now go on to learn about specific
2014-10-28 18:53:47 +08:00
_<<spring-boot-features#boot-features, Spring Boot features>>_ in depth, or you
2014-03-14 04:18:47 +08:00
could skip ahead and read about the
2014-10-28 18:53:47 +08:00
"`<<production-ready-features#production-ready, production ready>>`" aspects of Spring
2014-03-14 04:18:47 +08:00
Boot.