Spring Boot 1.3 introduces a new set of developer tools that make it easier to use Spring Boot while developing, including the following features.

  • Automatic restart: Automatically restarts running applications when files in the Classpath change.
  • LiveReload support: Changes to a resource automatically trigger a browser refresh.
  • Remote development: Automatic restart and LiveReload support for remote deployment.
  • Default development-time property values: Provide meaningful default development-time property values for some properties.

Spring Boot’s developer tools take the form of libraries that can be added to projects as dependencies. If you are using Gradle to build your projects, you can add development tools to the build. Gradle file as follows:

compile "org.springframework.boot:spring-boot-devtools"
Copy the code

Add Maven POM like this:

<dependency> 
 <groupId>org.springframework.boot</groupId> 
 <artifactId>spring-boot-devtools</artifactId> 
</dependency>
Copy the code

The developer tools are disabled when the application is running as a fully packaged JAR or WAR file, so there is no need to remove this dependency before building the production deployment package.

One, automatic restart

After the developer tools are enabled, any changes to the file in the Classpath will trigger an application restart. To make the restart fast, unmodified classes (such as those in third-party JAR files) are loaded into the base class loader, while the application code is loaded into a separate restart class loader. When changes are detected, only the restart classloader restarts.

Some resource changes in the Classpath do not require a restart of the application. View templates like Thymeleaf can be edited directly without restarting the application. Static resources in /static or /public also do not need to restart the application, so Spring Boot developer tools will exclude the following directories on reboot: / meta-inf /resources, /resources, /static, /public, and /templates.

. You can set the spring devtools. Restart. Exclude property to override the default restart out directory. For example, if you only exclude /static and /templates directories, you can set spring.devtools.restart. exclude like this:

spring: 
 devtools: 
 restart: 
 exclude: /static/**,/templates/**
Copy the code

On the other hand, if you want to completely shut down automatically restart, can spring. Devtools. Restart. Enabled is set to false:

spring: 
 devtools: 
 restart: 
 enabled: false
Copy the code

Alternatively, you can set up a trigger file that must be modified to trigger a restart. . For example, in the modified to trigger the file before you don’t want to restart, so you just need to set like this spring. The devtools. Restart. The trigger – file attributes:

spring: 
 devtools: 
 restart: 
 trigger-file: .trigger
Copy the code

Triggering files can be useful if your IDE compiles modified files continuously. Without the trigger file, each change triggers a restart. Having a trigger file ensures that a restart will only happen if you want to (just modify the trigger file).

Second, the LiveReload

The most common steps in Web application development are as follows:

  • Modify the content to render (such as images, stylesheets, templates).
  • Click the refresh button in your browser to see the results.
  • Go back to step 1.

It’s not that hard, but wouldn’t it be nice to see the changes without hitting refresh?

Spring Boot’s developer tools integrate with LiveReload (livereload.com) to eliminate the refresh step. When the developer tools are activated, Spring Boot launches an embedded LiveReload server that triggers a browser refresh when the resource file changes. All you have to do is install the LiveReload plugin in your browser.

If you want to disable the built-in LiveReload servers, can be spring. The devtools. LiveReload. Enabled is set to false:

spring: 
 devtools: 
 livereload: 
 enabled: false
Copy the code

Third, remote development

The auto-restart and LiveReload features of the developer tools are optional when running applications remotely, such as when deployed to a server or the cloud. In addition, the Spring Boot developer tool enables remote debugging of Spring Boot applications.

In traditional development, you don’t turn on remote development because it affects performance. But there are special scenarios where such tools can be useful. For example, the application being developed is deployed in a non-production environment for development purposes. This is especially true if the application is deployed in the cloud rather than in a local development environment.

You must set a remote security code to enable remote development:

spring: 
 devtools: 
 remote: 
 secret: myappsecret
Copy the code

With this property, the running application starts a server component to support remote development. It listens for requests to accept changes and can restart the application or trigger a browser refresh.

To use the remote server, you need to run the remote development tool client locally. This is a class a remote client, the fully qualified class name is org. Springframework. Boot. Devtools. RemoteSpringApplication. It runs inside the IDE and asks for a parameter to tell the remote application where to deploy.

For example, suppose you are running a readinglist application remotely, deployed on Cloud Foundry, at readinglist.cfapps.io. If you are using Eclipse or Spring ToolSuite, you can start the remote client by following these steps.

  1. Select the Run > Run Configurations menu item.
  2. Create a new Java Application to run the configuration.
  3. Select the Reading List Project in Project (you can find the Project by typing the Project name or clicking the Browse button, as shown in Figure A-1).
  4. Type it in Main Classorg.springframework.boot.devtools.RemoteSpringAppli-cation(See Figure A-1).
  5. Switch to the Arguments TAB and type readinglist.cfapps. IO in Program Arguments (see Figure A-2).

After the client starts, you can modify the application in the IDE. When changes are detected, these change points are pushed to the remote end and applied. LiveReload also triggers a browser refresh if the changes involve rendered Web resources, such as stylesheets or JavaScript.

Remote clients also enable http-based remote debugging channels so that applications deployed remotely can be debugged from within the IDE. All you need to do is make sure that remote debugging is enabled for the remote application. This is usually done by configuring JAVA_OPTS.

For example, if your application is deployed on Cloud Foundry, you can set JAVA_OPTS in your application’s manifest.yml as follows.

---
 env: 
  JAVA_OPTS: "-Xdebug -Xrunjdwp:server=y,transport=dt_socket,suspend=n"
Copy the code

When the remote application is started, a connection is established with the local debug server. You can set breakpoints and execute the code in the remote application step by step as if it were running locally (slower for network reasons).

Default development-time properties

Some configuration properties are usually set at development time and never in production. View template caching, for example, is best turned off during development so you can see the changes immediately. In a production environment, however, view template caching should be enabled for better performance.

By default, Spring Boot turns on caching options for the various view templates it supports (Thymeleaf, Freemarker, Velocity, Mustache, and Groovy templates). However, if Spring Boot’s developer tools exist, these caches are disabled.

In practice, this means that after the developer tool is activated, the following property is set to false:

  • spring.thymeleaf.cache
  • spring.freemarker.cache
  • spring.velocity.cache
  • spring.mustache.cache
  • spring.groovy.template.cache

This way, they do not have to be disabled at development time (in a Profile configuration used at development time).

Configure developer tools globally

You should have noticed that when using developer tools, you often use the same Settings for multiple projects. For example, if you use a restart trigger file, you are likely to use the same trigger file name in multiple projects. It is much easier to configure developer tools globally than to repeat developer tool configuration for each project.

To do this, create a file in your home directory called. Spring-boot-devtools.properties. (Note that the file name is “.” At the beginning. In that file, you can set various developer tool properties that you want to share across multiple projects.

For example, suppose you want to set the name of the trigger file to.trigger and disable LiveReload in all Spring Boot projects. You can create a.spring-boot-devtools.properties file with the following contents:

spring.devtools.restart.trigger-file=.trigger 
spring.devtools.livereload.enabled=false
Copy the code

If you want to override these configurations, you can set project-specific properties in each project’s application.properties or application.yml file.