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, add the module dependency to your build, as shown in the following listings for Maven and Gradle:
Maven.
<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-devtools</artifactId> <optional>true</optional> </dependency> </dependencies>
Gradle.
configurations {
developmentOnly
runtimeClasspath {
extendsFrom developmentOnly
}
}
dependencies {
developmentOnly("org.springframework.boot:spring-boot-devtools")
}
![]() | Note |
---|---|
Developer tools are automatically disabled when running a fully packaged application.
If your application is launched from |
![]() | Tip |
---|---|
Flagging the dependency as optional in Maven or using a custom`developmentOnly` configuration in Gradle (as shown above) is a best practice that prevents devtools from being transitively applied to other modules that use your project. |
![]() | Tip |
---|---|
Repackaged archives do not contain devtools by default.
If you want to use a certain remote devtools feature, you need to disable the |
Several of the libraries supported by Spring Boot use caches to improve performance. For example, template engines cache compiled templates to avoid repeatedly parsing template files. Also, Spring MVC can add HTTP caching headers to responses when serving static resources.
While caching is very beneficial in production, it can be counter-productive during development, preventing you from seeing the changes you just made in your application. For this reason, spring-boot-devtools disables the caching options by default.
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 automatically applies sensible development-time configuration.
Because you need more information about web requests while developing Spring MVC and Spring WebFlux applications, developer tools will enable DEBUG
logging for the web
logging group.
This will give you information about the incoming request, which handler is processing it, the response outcome, etc.
If you wish to log all request details (including potentially sensitive information), you can turn on the spring.http.log-request-details
configuration property.
![]() | Note |
---|---|
If you don’t want property defaults to be applied you can set |
![]() | Tip |
---|---|
For a complete list of the properties that are applied by the devtools, see DevToolsPropertyDefaultsPostProcessor. |
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 a very fast feedback loop for code changes.
By default, any entry on the classpath that points to a folder is monitored for changes.
Note that certain resources, such as static assets and view templates, do not need to restart the application.
![]() | Note |
---|---|
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 DevTools on the classpath. |
![]() | Tip |
---|---|
Automatic restart works very well when used with LiveReload. See the LiveReload section for details. If you use JRebel, automatic restarts are disabled in favor of dynamic class reloading. Other devtools features (such as LiveReload and property overrides) can still be used. |
![]() | Note |
---|---|
DevTools relies on the application context’s shutdown hook to close it during a restart.
It does not work correctly if you have disabled the shutdown hook ( |
![]() | Note |
---|---|
When deciding if an entry on the classpath should trigger a restart when it changes, DevTools automatically ignores projects named |
![]() | Note |
---|---|
DevTools needs to customize the |
By default, each time your application restarts, a report showing the condition evaluation delta is logged. The report shows the changes to your application’s auto-configuration as you make changes such as adding or removing beans and setting configuration properties.
To disable the logging of the report, set the following property:
spring.devtools.restart.log-condition-evaluation-delta=false
Certain resources do not necessarily need to trigger a restart when they are changed.
For example, Thymeleaf templates can be edited in-place.
By default, changing resources in /META-INF/maven
, /META-INF/resources
, /resources
, /static
, /public
, or /templates
does not trigger a restart but does trigger a live reload.
If you want to customize these exclusions, you can use the spring.devtools.restart.exclude
property.
For example, to exclude only /static
and /public
you would set the following property:
spring.devtools.restart.exclude=static/**,public/**
![]() | Tip |
---|---|
If you want to keep those defaults and add additional exclusions, use the |
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 described earlier to control whether changes beneath the additional paths trigger a full restart or a live reload.
If you do not want to use the restart feature, you can disable it by using the spring.devtools.restart.enabled
property.
In most cases, you can set this property in your application.properties
(doing so still initializes the restart classloader, but it does not watch for file changes).
If you need to completely disable restart support (for example, because it does not 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:
public static void main(String[] args) { System.setProperty("spring.devtools.restart.enabled", "false"); SpringApplication.run(MyApp.class, args); }
If you work with an IDE that continuously compiles changed files, you might prefer to trigger restarts only at specific times. To do so, you can use a “trigger file”, which is a special file that must be modified when you want to actually trigger a restart check.
![]() | Note |
---|---|
Any update to the file will trigger a check, but restart only actually occurs if Devtools has detected it has something to do. |
To use a trigger file, set the spring.devtools.restart.trigger-file
property to the name (excluding any path) of your trigger file.
The trigger file must appear somewhere on your classpath.
For example, if you have a project with the following structure:
src +- main +- resources +- .reloadtrigger
Then your trigger-file
property would be:
spring.devtools.restart.trigger-file=.reloadtrigger
Restarts will now only happen when the src/main/resources/.reloadtrigger
is updated.
![]() | Tip |
---|---|
You might want to set |
Some IDEs have features that save you from needing to update your trigger file manually.
Spring Tools for Eclipse and IntelliJ IDEA (Ultimate Edition) both have such support.
With Spring Tools, you can use the “reload” button from the console view (as long as your trigger-file
is named .reloadtrigger
).
For IntelliJ, you can follow the instructions in their documentation.
As described earlier in the Restart vs Reload section, restart functionality is implemented by using two classloaders. For most applications, this approach works well. However, it can sometimes cause classloading issues.
By default, any open project in your IDE is loaded with the “restart” classloader, and any regular .jar
file is loaded with the “base” classloader.
If you work on a multi-module project, and not every module is imported into your IDE, you may need to customize things.
To do so, you can create a META-INF/spring-devtools.properties
file.
The spring-devtools.properties
file can contain properties prefixed with restart.exclude
and restart.include
.
The include
elements are items that should be pulled up into the “restart” classloader, and the exclude
elements are items that should be pushed down into the “base” classloader.
The value of the property is a regex pattern that is applied to the classpath, as shown in the following example:
restart.exclude.companycommonlibs=/mycorp-common-[\\w\\d-\.]+\.jar restart.include.projectcommon=/mycorp-myproj-[\\w\\d-\.]+\.jar
![]() | Note |
---|---|
All property keys must be unique.
As long as a property starts with |
![]() | Tip |
---|---|
All |
Restart functionality does not work well with objects that are deserialized by using a standard ObjectInputStream
.
If you need to deserialize data, you may need to use Spring’s ConfigurableObjectInputStream
in combination with Thread.currentThread().getContextClassLoader()
.
Unfortunately, several third-party libraries deserialize without considering the context classloader. If you find such a problem, you need to request a fix with the original authors.
The 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 do not 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. Before starting your application, ensure that no other LiveReload servers are running. If you start multiple applications from your IDE, only the first has 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 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 property:
~/.spring-boot-devtools.properties.
spring.devtools.reload.trigger-file=.reloadtrigger
![]() | Note |
---|---|
Profiles are not supported in devtools properties/yaml files. Any profiles activated in |
The Spring Boot developer tools are not limited to local development. You can also use several features when running applications remotely. Remote support is opt-in as enabling it can be a security risk. It should only be enabled when running on a trusted network or when secured with SSL. If neither of these options is available to you, you should not use DevTools' remote support. You should never enable support on a production deployment.
To enable it, you need to make sure that devtools
is included in the repackaged archive, as shown in the following listing:
<build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <configuration> <excludeDevtools>false</excludeDevtools> </configuration> </plugin> </plugins> </build>
Then you need to set the spring.devtools.remote.secret
property.
Like any important password or secret, the value should be unique and strong such that it cannot be guessed or brute-forced.
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 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 your IDE.
You need to run org.springframework.boot.devtools.RemoteSpringApplication
with the same classpath as the remote project that you connect to.
The application’s single required argument is the remote URL to which it connects.
For example, if you are using Eclipse or STS and you have a project named my-app
that you have deployed to Cloud Foundry, you would do the following:
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 might resemble the following listing:
. ____ _ __ _ _ /\\ / ___'_ __ _ _(_)_ __ __ _ ___ _ \ \ \ \ ( ( )\___ | '_ | '_| | '_ \/ _` | | _ \___ _ __ ___| |_ ___ \ \ \ \ \\/ ___)| |_)| | | | | || (_| []::::::[] / -_) ' \/ _ \ _/ -_) ) ) ) ) ' |____| .__|_| |_|_| |_\__, | |_|_\___|_|_|_\___/\__\___|/ / / / =========|_|==============|___/===================================/_/_/_/ :: Spring Boot Remote :: 2.1.19.BUILD-SNAPSHOT 2015-06-10 18:25:06.632 INFO 14938 --- [ main] o.s.b.devtools.RemoteSpringApplication : Starting RemoteSpringApplication on pwmbp with PID 14938 (/Users/pwebb/projects/spring-boot/code/spring-boot-devtools/target/classes started by pwebb in /Users/pwebb/projects/spring-boot/code/spring-boot-samples/spring-boot-sample-devtools) 2015-06-10 18:25:06.671 INFO 14938 --- [ main] s.c.a.AnnotationConfigApplicationContext : Refreshing org.springframework.context.annotation.AnnotationConfigApplicationContext@2a17b7b6: startup date [Wed Jun 10 18:25:06 PDT 2015]; root of context hierarchy 2015-06-10 18:25:07.043 WARN 14938 --- [ main] o.s.b.d.r.c.RemoteClientConfiguration : The connection to http://localhost:8080 is insecure. You should use a URL starting with 'https://'. 2015-06-10 18:25:07.074 INFO 14938 --- [ main] o.s.b.d.a.OptionalLiveReloadServer : LiveReload server is running on port 35729 2015-06-10 18:25:07.130 INFO 14938 --- [ main] o.s.b.devtools.RemoteSpringApplication : Started RemoteSpringApplication in 0.74 seconds (JVM running for 1.105)
![]() | 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 is always advisable to use |
![]() | Tip |
---|---|
If you need to use a proxy to access the remote application, configure the |
The remote client monitors your application classpath for changes in the same way as the local restart. Any updated resource is pushed to the remote application and (if required) triggers a restart. This can be helpful if you iterate on a feature that uses a cloud service that you do not have locally. Generally, remote updates and restarts are much quicker than a full rebuild and deploy cycle.
![]() | Note |
---|---|
Files are only monitored when the remote client is running. If you change a file before starting the remote client, it is not pushed to the remote server. |
FileSystemWatcher works by polling the class changes with a certain time interval, and then waiting for a predefined quiet period to make sure there are no more changes. The changes are then uploaded to the remote application. On a slower development environment, it may happen that the quiet period is not enough, and the changes in the classes may be split into batches. The server is restarted after the first batch of class changes is uploaded. The next batch can’t be sent to the application, since the server is restarting.
This is typically manifested by a warning in the RemoteSpringApplication
logs about failing to upload some of the classes, and a consequent retry.
But it may also lead to application code inconsistency and failure to restart after the first batch of changes is uploaded.
If you observe such problems constantly, try increasing the spring.devtools.restart.poll-interval
and spring.devtools.restart.quiet-period
parameters to the values that fit your development environment:
spring.devtools.restart.poll-interval=2s spring.devtools.restart.quiet-period=1s
The monitored classpath folders are now polled every 2 seconds for changes, and a 1 second quiet period is maintained to make sure there are no additional class changes.
If you have Spring Security on the classpath, you may observe HTTP error 401 or 403 in the logs of the RemoteSpringApplication
:
Exception in thread "File Watcher" java.lang.IllegalStateException: Unexpected 401 UNAUTHORIZED response uploading class files
The URL for class uploading should be exempted both from the web security and from the csrf filter. The following example shows how anonymous access to the remote devtools endpoint can be configured:
@Configuration public class SecurityConfiguration extends WebSecurityConfigurerAdapter { @Override protected void configure(HttpSecurity http) throws Exception { http.requestMatchers("/.~~spring-boot!~/restart").anyRequest().anonymous() .and().csrf().disable(); } }
![]() | Note |
---|---|
The above configuration will only affect the remote devtools endpoint. Spring Boot’s default security auto-configuration will still apply to the rest of the application. If the rest of the application requires custom security, it needs to be configured separately. |