Optimize your development experience with Spring Boot DevTools

scenes

One day the teenager received a message from the front end of the students that the interface response of the joint investigation is abnormal 🙃, the teenager is very calm 🙂, because this kind of thing is too common 😑. I asked for details and opened my own code to find out what the problem was, and within five minutes I found it. After modifying the code, the teenager stopped the local project and then restarted it. As the current server project is a huge single app that takes three or four minutes to start, he took out his phone and started to check moments. Brush brush (due to distraction unconsciously spent more than ten minutes) suddenly realized that the project has been restarted, so inform the front end students to check the effect.

To analyze problems

The above scenario may be familiar to many developers, as changes to projects are common and frequent during development. When we have made changes to code or other files, we will restart the project to verify that the changes actually took effect (ignoring the test code we wrote here), so that the front-end or other clients can use our changes. But this process wastes a lot of time and even forces us to distract ourselves (checking social media, reading the news, chatting with colleagues), which is a great threat to our productivity.

spring-boot-devtools

Is there a way to make changes to the project go into effect quickly and save time we could have used instead? Fortunately, there is a tool to solve this problem: **Spring Boot Dev Tools**.

Introduction of the principle

You might say that it’s not important to know how Spring Boot Dev Tools works, but because there are so many complexities in the development process, it’s helpful to know how Spring Boot Dev Tools works.

Spring Boot Dev Tools hooks into Spring Boot’s classloader to provide a way to restart an application context or reload static files that have changed on demand without restarting the entire application.

To do this, Spring Boot Dev Tools divides the application’s classpath and assigns it to two different classloaders:

• Base Classloader: Contains immutable classes or files that will rarely be modified, such as Spring Boot JARS or third-party libraries.
• Restart Classloader: Files containing applications that will change frequently during the development of the project.

After restarting the application, the existing restart classloader is discarded and the new restart classloader is started. This approach means that an application typically restarts much faster than a “cold start” because the base class loader is unaffected and always exists.

Introduction of depend on

When we created our project using Intellij IDEA’s Spring Initializr, Spring Initializr provided a built-in Spring Boot Dev Tools dependency option that we could simply select.

Spring InitializrThe introduction ofSpring Boot Dev Tools

Maven project introductionSpring Boot Dev Tools

Import the Spring Boot Dev Tools dependency in the project’s POM.xml file

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

Project presentations

A single module

Add a simple Controller to your project

@SpringBootApplication
public class DevToolApplication {

    public static void main(String[] args) {
        SpringApplication.run(DevToolApplication.class, args);
    }

    @RestController
    public static class HelloWorld {
        @GetMapping("test")
        publicResponseEntity<? > getTest() {return ResponseEntity.ok("hello world"); }}}Copy the code

Start the project, visit http://localhost:8080/test, return is as follows:

We simply modify the code

@RestController
public static class HelloWorld {
    @GetMapping("test")
    publicResponseEntity<? > getTest() {return ResponseEntity.ok("hello world after change file"); }}Copy the code

Run the command MVN compile, run over to visit http://localhost:8080/test

As you can see, our changes have taken effect.

Multiple modules

Suppose our project now references other projects as submodules

<dependency>
    <groupId>org.example</groupId>
    <artifactId>untitled</artifactId>
    <version>1.0 the SNAPSHOT</version>
</dependency>
Copy the code

We need the changes to the above submodules to take effect immediately while the program is running.

Using Spring Boot Dev Tools in a multi-module project is slightly more complicated than in a single-module project, because the main module is a reference to the submodules in a multi-module project, and the main module starts the application at run time by referencing the submodules’ JAR files. According to Spring Boot Dev Tools, jar files will be loaded by the base class loader, so changes to submodules will not take effect immediately.

However, Spring Boot Dev Tools provides support for multi-module projects, and we only need to add a simple configuration to make changes to multi-module projects effective immediately.

Create the meta-INF /spring-devtools.properties file in/Resources of the project and add the configuration

restart.include.projectcommon=/ untitled - 1.0 - the SNAPSHOT. The jar
Copy the code

The above configuration indicates that the restart classloader loads the latest submodule dependencies when it restarts, so that changes to submodules take effect immediately.

The following classes now exist in the submodule

public class DemoA {
    private String name;

    public String getName(a) {
        return name;
    }

    public DemoA setName(String name) {
        this.name = name+"cgsj111";
        return this; }}Copy the code

The above class is referenced in the main module

@RestController
public static class HelloWorld {
    @GetMapping("test")
    publicResponseEntity<? > getTest() { DemoA demo =new DemoA();
        demo.setName("demo name");
        returnResponseEntity.ok(demo); }}Copy the code

Now start the application, visit http://localhost:8080/test

You can see that the response comes back normally, at which point we modify the code for the submodule

public class DemoA {
    private String name;

    public String getName(a) {
        return name;
    }

    public DemoA setName(String name) {
        this.name = name+"cgsj111 After Change";
        return this; }}Copy the code

Then run the command MVN compile in the main module, at which point the interface is accessed again

You can see that the submodule changes have taken effect immediately in the main module.

Remote debugging

The benefits of Spring Boot Dev Tools are not limited to local debugging, but also provide great support for remote debugging. Enable remote support selectively because enabling it may pose a security risk. It should only be enabled when running on a trusted network or using SSL protection. If neither of these options is met, then DevTools’s remote support should not be used. You should never enable it in a production environment.

To enable it, make sure devTools is included in the build, modify it to the following configuration:

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <configuration>
                <! -- Make sure the project package includes Devtools -->
                <excludeDevtools>false</excludeDevtools>
            </configuration>
        </plugin>
    </plugins>
</build>
Copy the code

Then, you need to set up spring. Devtools. Remote. The secret properties. Like any important password or secret, this value should be unique and strong so that it can’t be guessed or forcibly used, for example, set in application.properties:

spring.devtools.remote.secret=cgsj8377
Copy the code

Remote DevTools support is divided into two parts: server-side endpoints that accept connections and client-side applications that run in the IDE. Set up spring. Devtools. Remote. The nature of the secret, will be automatically enabled server components, client components must be started manually.

Debug the demonstration

Run the command MVN package in the project folder to generate the JAR files and deploy them to the server (here we simulate remote deployment by running the JAR packages locally). Then do the following configuration in the IDE (take Intellij IDEA as an example)

As shown above, we added a starter start class for org. Springframework. Boot. Devtools. RemoteSpringApplication, passed a program and parameter to specify the address of the remote application, Here I test on this machine so it is a local address.

Next we start the initiator we just created

The startup log is as follows

Modify the code to the following

@RestController
public static class HelloWorld {
    @GetMapping("test")
    publicResponseEntity<? > getTest() { DemoA demo =new DemoA();
        demo.setName("remote test");
        returnResponseEntity.ok(demo); }}Copy the code

Then run the command MVN compile and you can see that our changes take effect immediately in the running program

conclusion

There are all sorts of “waits” in our daily development process, and these moments can greatly affect a developer’s productivity and focus. The emergence of Developer Tools alleviates this problem, which makes the application debugging more convenient and efficient. One thing to note is that before making our changes take effect we need to execute the MVN compile command so that the native code is compiled into a bytecode file that the program can understand.

Sample code for this article:Gitee.com/jeker8chen/…

References for this article:

Docs. Spring. IO/spring – the boot…

Reflectoring. IO/spring – the boot…

🌟 🌟 🌟 🌟 🌟 🌟 🌟 🌟 🌟 🌟 🌟 🌟 🌟 🌟 🌟 🌟 🌟 🌟

Welcome to my blog:blog.dongxishaonian.tech