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. To enable it, you need to make sure that     
devtools is included in the repackaged archive, as shown in the following     
listing:

Then you need to set a spring.devtools.remote.secret property,     
as shown in the following example:

Enabling spring-boot-devtools on a remote application is a security     
risk. You should never enable support on a production deployment.

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:

•	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.
•	Add https://myapp.cfapps.io to the Program arguments (or whatever your remote URL is).

Because the remote client is using the same classpath as the real     
application it can directly read application properties. This is how     
the spring.devtools.remote.secret property is read and passed to the     
server for authentication.

It is always advisable to use https:// as the connection protocol,      
so that traffic is encrypted and passwords cannot be intercepted.

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.

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.

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.

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.

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:

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.      
Changing the file only triggers the check and the restart only occurs      
if Devtools has detected it has to do something. The trigger file can      
be updated manually or with an IDE plugin.

To use a trigger file, set the spring.devtools.restart.trigger-file     
property to the path of your trigger file.

You might want to set spring.devtools.restart.trigger-file as     
a global setting, so that all your projects behave in the same way.

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:

All property keys must be unique. As long as a property     
starts with restart.include. or restart.exclude. it is considered.

All META-INF/spring-devtools.properties from the classpath are loaded.     
You can package files inside your project, or in the libraries that     
the project consumes.

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:

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:

If you want to keep those defaults and add additional exclusions,    
use the spring.devtools.restart.additional-exclude property instead.

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:

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.

Triggering a restart
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 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 -> Build Project)     
has the same effect.

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.

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.

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 (SpringApplication.setRegisterShutdownHook(false)).

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.

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 the getResource     
method on the ApplicationContext is not supported.

Restart vs Reload
The restart technology provided by Spring Boot works by using     
two classloaders. 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 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 faster than “cold starts”, since the base     
classloader is already available and populated.
If you find that restarts are not quick enough for your applications     
or you encounter classloading issues, you could consider reloading     
technologies such as JRebelfrom ZeroTurnaround. These work by rewriting     
classes as they are loaded to make them more amenable to reloading.

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:

Developer tools are automatically disabled when running a      
fully packaged application. If your application is launched     
from java -jar or if it is started from a special classloader,     
then it is considered a “production application”. Flagging the     
dependency as optional in Maven or using compileOnly in Gradle     
is a best practice that prevents devtools from being transitively     
applied to other modules that use your project.

Repackaged archives do not contain devtools by default. If     
you want to use a certain remote devtools feature, you need     
to disable the excludeDevtoolsbuild property to include it.     
The property is supported with both the Maven and Gradle plugins.

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.

For a complete list of the properties that are applied     
by the devtools, see DevToolsPropertyDefaultsPostProcessor.

One of the biggest advantages of packaging your application as     
a 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 do not need any special IDE plugins     
or extensions.

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, 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 can select Import…  → Existing Maven Projects from the File menu.

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 Eclipse and IDEA. Gradle offers plugins     
for various IDEs.

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 any existing     
instance is closed.

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:

It is also possible to run a packaged application with remote     
debugging support enabled. Doing so lets you attach a debugger     
to your packaged application, as shown in the following example:

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. The following     
example shows a typical Maven command to run a Spring Boot application:

You might also want to use the MAVEN_OPTS operating system     
environment variable, as shown in the following example:

The Spring Boot Gradle plugin also includes a bootRun task that can     
be used to run your application in an exploded form. The bootRun     
task is added whenever you apply the org.springframework.boot and     
java plugins and is shown in the following example:

You might also want to use the JAVA_OPTS operating system     
environment variable, as shown in the following example:

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 can be used.

The spring-boot-devtools module also includes support for     
quick application restarts. See the Chapter 20, Developer     
Tools section later in this chapter and theHot swapping     
“How-to” for details.

Many Spring Boot developers like their apps to use auto-configuration,     
component scan and be able to define extra configuration on their     
"application class". A single@SpringBootApplication annotation     
can be used to enable those tree features, that is:

* @EnableAutoConfiguration: enable Spring Boot’s auto-configuration mechanism
* @ComponentScan: enable @Component scan on the package where the application is located (see the best practices)
* @Configuration: allow to register extra beans in the context or import additional configuration classes

@SpringBootApplication also provides aliases to customize the     
attributes of @EnableAutoConfiguration and @ComponentScan.

None of these features are mandatory and you may chose to     
replace this single annotation by any of the features that it     
enables. For instance, you may not want to use component scan     
in your application:

In this example, Application is just like any other Spring Boot     
application except that @Component-annotated classes are not     
detected automatically and the user-defined beans are imported     
explicitly (see @Import).