Provide both properties and YAML examples in docs
Update all configuration examples in the docs to YAML and make use of the new `configblocks` spring-asciidoctor-extensions feature to automatically create both "Properties" and "Yaml" versions. Closes gh-23515
This commit is contained in:
Phillip Webb
@@ -85,7 +85,7 @@ See "`<<spring-boot-features.adoc#boot-features-application-events-and-listeners
|
||||
It is also possible to customize the `Environment` before the application context is refreshed by using `EnvironmentPostProcessor`.
|
||||
Each implementation should be registered in `META-INF/spring.factories`, as shown in the following example:
|
||||
|
||||
[source,properties,indent=0]
|
||||
[indent=0]
|
||||
----
|
||||
org.springframework.boot.env.EnvironmentPostProcessor=com.example.YourEnvironmentPostProcessor
|
||||
----
|
||||
@@ -145,10 +145,12 @@ This is possible in both Maven and Gradle.
|
||||
You can automatically expand properties from the Maven project by using resource filtering.
|
||||
If you use the `spring-boot-starter-parent`, you can then refer to your Maven '`project properties`' with `@..@` placeholders, as shown in the following example:
|
||||
|
||||
[source,properties,indent=0]
|
||||
[source,yaml,indent=0,configblocks]
|
||||
----
|
||||
app.encoding=@project.build.sourceEncoding@
|
||||
app.java.version=@java.version@
|
||||
app:
|
||||
encoding: "@project.build.sourceEncoding@"
|
||||
java:
|
||||
version: "@java.version@"
|
||||
----
|
||||
|
||||
NOTE: Only production configuration is filtered that way (in other words, no filtering is applied on `src/test/resources`).
|
||||
@@ -205,10 +207,11 @@ You can automatically expand properties from the Gradle project by configuring t
|
||||
|
||||
You can then refer to your Gradle project's properties by using placeholders, as shown in the following example:
|
||||
|
||||
[source,properties,indent=0]
|
||||
[source,yaml,indent=0,configblocks]
|
||||
----
|
||||
app.name=${name}
|
||||
app.description=${description}
|
||||
app:
|
||||
name: "${name}"
|
||||
description: "${description}"
|
||||
----
|
||||
|
||||
NOTE: Gradle's `expand` method uses Groovy's `SimpleTemplateEngine`, which transforms `${..}` tokens.
|
||||
@@ -223,10 +226,12 @@ A `SpringApplication` has bean properties (mainly setters), so you can use its J
|
||||
Alternatively, you can externalize the configuration by setting properties in `+spring.main.*+`.
|
||||
For example, in `application.properties`, you might have the following settings:
|
||||
|
||||
[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
|
||||
[source,yaml,indent=0,subs="verbatim,quotes,attributes",configprops,configblocks]
|
||||
----
|
||||
spring.main.web-application-type=none
|
||||
spring.main.banner-mode=off
|
||||
spring:
|
||||
main:
|
||||
web-application-type: "none"
|
||||
banner-mode: "off"
|
||||
----
|
||||
|
||||
Then the Spring Boot banner is not printed on startup, and the application is not starting an embedded web server.
|
||||
@@ -244,10 +249,12 @@ Consider the following application:
|
||||
|
||||
Now consider the following configuration:
|
||||
|
||||
[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
|
||||
[source,yaml,indent=0,subs="verbatim,quotes,attributes",configprops,configblocks]
|
||||
----
|
||||
spring.main.sources=com.acme.Config,com.acme.ExtraConfig
|
||||
spring.main.banner-mode=console
|
||||
spring:
|
||||
main:
|
||||
sources: "com.acme.Config,com.acme.ExtraConfig"
|
||||
banner-mode: "console"
|
||||
----
|
||||
|
||||
The actual application _now_ shows the banner (as overridden by configuration) and uses three sources for the `ApplicationContext` (in the following order): `demo.MyApp`, `com.acme.Config`, and `com.acme.ExtraConfig`.
|
||||
@@ -278,9 +285,10 @@ See {spring-boot-module-code}/context/config/ConfigFileApplicationListener.java[
|
||||
Some people like to use (for example) `--port=9000` instead of `--server.port=9000` to set configuration properties on the command line.
|
||||
You can enable this behavior by using placeholders in `application.properties`, as shown in the following example:
|
||||
|
||||
[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
|
||||
[source,yaml,indent=0,subs="verbatim,quotes,attributes",configprops,configblocks]
|
||||
----
|
||||
server.port=${port:8080}
|
||||
server:
|
||||
port: "${port:8080}"
|
||||
----
|
||||
|
||||
TIP: If you inherit from the `spring-boot-starter-parent` POM, the default filter token of the `maven-resources-plugins` has been changed from `+${*}+` to `@` (that is, `@maven.token@` instead of `${maven.token}`) to prevent conflicts with Spring-style placeholders.
|
||||
@@ -298,13 +306,13 @@ YAML is a superset of JSON and, as such, is a convenient syntax for storing exte
|
||||
[source,yaml,indent=0,subs="verbatim,quotes,attributes"]
|
||||
----
|
||||
spring:
|
||||
application:
|
||||
name: cruncher
|
||||
datasource:
|
||||
driverClassName: com.mysql.jdbc.Driver
|
||||
url: jdbc:mysql://localhost/test
|
||||
application:
|
||||
name: "cruncher"
|
||||
datasource:
|
||||
driver-class-name: "com.mysql.jdbc.Driver"
|
||||
url: "jdbc:mysql://localhost/test"
|
||||
server:
|
||||
port: 9000
|
||||
port: 9000
|
||||
----
|
||||
|
||||
Create a file called `application.yml` and put it in the root of your classpath.
|
||||
@@ -337,9 +345,11 @@ Also, you can launch your application with a `-D` argument (remember to put it b
|
||||
|
||||
In Spring Boot, you can also set the active profile in `application.properties`, as shown in the following example:
|
||||
|
||||
[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
|
||||
[source,yaml,indent=0,subs="verbatim,quotes,attributes",configprops,configblocks]
|
||||
----
|
||||
spring.profiles.active=production
|
||||
spring:
|
||||
profiles:
|
||||
active: "production"
|
||||
----
|
||||
|
||||
A value set this way is replaced by the System property or environment variable setting but not by the `SpringApplicationBuilder.profiles()` method.
|
||||
@@ -356,15 +366,24 @@ Spring Boot supports multi-document YAML and Properties files (see <<spring-boot
|
||||
If a document contains a `spring.config.activate.on-profile` key, then the profiles value (a comma-separated list of profiles or a profile expression) is fed into the Spring `Environment.acceptsProfiles()` method.
|
||||
If the profile expression matches then that document is included in the final merge (otherwise, it is not), as shown in the following example:
|
||||
|
||||
[source,yaml,indent=0,subs="verbatim,quotes,attributes"]
|
||||
[source,yaml,indent=0,subs="verbatim,quotes,attributes",configprops,configblocks]
|
||||
----
|
||||
server.port: 9000
|
||||
server:
|
||||
port: 9000
|
||||
---
|
||||
spring.config.activate.on-profile: development
|
||||
server.port: 9001
|
||||
spring:
|
||||
config:
|
||||
activate:
|
||||
on-profile: "development"
|
||||
server:
|
||||
port: 9001
|
||||
---
|
||||
spring.config.activate.on-profile: production
|
||||
server.port: 0
|
||||
spring:
|
||||
config:
|
||||
activate:
|
||||
on-profile: "production"
|
||||
server:
|
||||
port: 0
|
||||
----
|
||||
|
||||
In the preceding example, the default port is 9000.
|
||||
@@ -461,9 +480,11 @@ NOTE: `spring-boot-starter-reactor-netty` is required to use the `WebClient` cla
|
||||
If your classpath contains the necessary bits to start a web server, Spring Boot will automatically start it.
|
||||
To disable this behavior configure the `WebApplicationType` in your `application.properties`, as shown in the following example:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
spring.main.web-application-type=none
|
||||
spring:
|
||||
main:
|
||||
web-application-type: "none"
|
||||
----
|
||||
|
||||
|
||||
@@ -520,9 +541,11 @@ Contrary to a test, application code callbacks are processed early (before the v
|
||||
HTTP response compression is supported by Jetty, Tomcat, and Undertow.
|
||||
It can be enabled in `application.properties`, as follows:
|
||||
|
||||
[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
|
||||
[source,yaml,indent=0,subs="verbatim,quotes,attributes",configprops,configblocks]
|
||||
----
|
||||
server.compression.enabled=true
|
||||
server:
|
||||
compression:
|
||||
enabled: true
|
||||
----
|
||||
|
||||
By default, responses must be at least 2048 bytes in length for compression to be performed.
|
||||
@@ -548,12 +571,14 @@ You can configure this behavior by setting the configprop:server.compression.mim
|
||||
SSL can be configured declaratively by setting the various `+server.ssl.*+` properties, typically in `application.properties` or `application.yml`.
|
||||
The following example shows setting SSL properties in `application.properties`:
|
||||
|
||||
[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
|
||||
[source,yaml,indent=0,subs="verbatim,quotes,attributes",configprops,configblocks]
|
||||
----
|
||||
server.port=8443
|
||||
server.ssl.key-store=classpath:keystore.jks
|
||||
server.ssl.key-store-password=secret
|
||||
server.ssl.key-password=another-secret
|
||||
server:
|
||||
port: 8443
|
||||
ssl:
|
||||
key-store: "classpath:keystore.jks"
|
||||
key-store-password: "secret"
|
||||
key-password: "another-secret"
|
||||
----
|
||||
|
||||
See {spring-boot-module-code}/web/server/Ssl.java[`Ssl`] for details of all of the supported properties.
|
||||
@@ -742,11 +767,14 @@ Access logs can be configured for Tomcat, Undertow, and Jetty through their resp
|
||||
|
||||
For instance, the following settings log access on Tomcat with a {tomcat-docs}/config/valve.html#Access_Logging[custom pattern].
|
||||
|
||||
[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
|
||||
[source,yaml,indent=0,subs="verbatim,quotes,attributes",configprops,configblocks]
|
||||
----
|
||||
server.tomcat.basedir=my-tomcat
|
||||
server.tomcat.accesslog.enabled=true
|
||||
server.tomcat.accesslog.pattern=%t %a "%r" %s (%D ms)
|
||||
server:
|
||||
tomcat:
|
||||
basedir: "my-tomcat"
|
||||
accesslog:
|
||||
enabled: true
|
||||
pattern: "%t %a %r %s (%D ms)"
|
||||
----
|
||||
|
||||
NOTE: The default location for logs is a `logs` directory relative to the Tomcat base directory.
|
||||
@@ -755,10 +783,13 @@ In the preceding example, the logs are available in `my-tomcat/logs` relative to
|
||||
|
||||
Access logging for Undertow can be configured in a similar fashion, as shown in the following example:
|
||||
|
||||
[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
|
||||
[source,yaml,indent=0,subs="verbatim,quotes,attributes",configprops,configblocks]
|
||||
----
|
||||
server.undertow.accesslog.enabled=true
|
||||
server.undertow.accesslog.pattern=%t %a "%r" %s (%D ms)
|
||||
server:
|
||||
undertow:
|
||||
accesslog:
|
||||
enabled: true
|
||||
pattern: "%t %a %r %s (%D ms)"
|
||||
----
|
||||
|
||||
Logs are stored in a `logs` directory relative to the working directory of the application.
|
||||
@@ -766,10 +797,13 @@ You can customize this location by setting the configprop:server.undertow.access
|
||||
|
||||
Finally, access logging for Jetty can also be configured as follows:
|
||||
|
||||
[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
|
||||
[source,yaml,indent=0,subs="verbatim,quotes,attributes",configprops,configblocks]
|
||||
----
|
||||
server.jetty.accesslog.enabled=true
|
||||
server.jetty.accesslog.filename=/var/log/jetty-access.log
|
||||
server:
|
||||
jetty:
|
||||
accesslog:
|
||||
enabled: true
|
||||
filename: "/var/log/jetty-access.log"
|
||||
----
|
||||
|
||||
By default, logs are redirected to `System.err`.
|
||||
@@ -801,24 +835,27 @@ In all other instances, it defaults to `NONE`.
|
||||
==== Customize Tomcat's Proxy Configuration
|
||||
If you use Tomcat, you can additionally configure the names of the headers used to carry "`forwarded`" information, as shown in the following example:
|
||||
|
||||
[indent=0]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
server.tomcat.remoteip.remote-ip-header=x-your-remote-ip-header
|
||||
server.tomcat.remoteip.protocol-header=x-your-protocol-header
|
||||
server:
|
||||
tomcat:
|
||||
remoteip:
|
||||
remote-ip-header: "x-your-remote-ip-header"
|
||||
protocol-header: "x-your-protocol-header"
|
||||
----
|
||||
|
||||
Tomcat is also configured with a default regular expression that matches internal proxies that are to be trusted.
|
||||
By default, IP addresses in `10/8`, `192.168/16`, `169.254/16` and `127/8` are trusted.
|
||||
You can customize the valve's configuration by adding an entry to `application.properties`, as shown in the following example:
|
||||
|
||||
[indent=0]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
server.tomcat.remoteip.internal-proxies=192\\.168\\.\\d{1,3}\\.\\d{1,3}
|
||||
server:
|
||||
tomcat:
|
||||
remoteip:
|
||||
internal-proxies: "192\\.168\\.\\d{1,3}\\.\\d{1,3}"
|
||||
----
|
||||
|
||||
NOTE: The double backslashes are required only when you use a properties file for configuration.
|
||||
If you use YAML, single backslashes are sufficient, and a value equivalent to that shown in the preceding example would be `192\.168\.\d{1,3}\.\d{1,3}`.
|
||||
|
||||
NOTE: You can trust all proxies by setting the `internal-proxies` to empty (but do not do so in production).
|
||||
|
||||
You can take complete control of the configuration of Tomcat's `RemoteIpValve` by switching the automatic one off (to do so, set `server.forward-headers-strategy=NONE`) and adding a new valve instance in a `TomcatServletWebServerFactory` bean.
|
||||
@@ -890,9 +927,12 @@ Embedded Tomcat's MBean registry is disabled by default.
|
||||
This minimizes Tomcat's memory footprint.
|
||||
If you want to use Tomcat's MBeans, for example so that they can be used to expose metrics via Micrometer, you must use the configprop:server.tomcat.mbeanregistry.enabled[] property to do so, as shown in the following example:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
server.tomcat.mbeanregistry.enabled=true
|
||||
server:
|
||||
tomcat:
|
||||
mbeanregistry:
|
||||
enabled: true
|
||||
----
|
||||
|
||||
|
||||
@@ -1110,9 +1150,12 @@ NOTE: It is recommended to use the container's built-in support for multipart up
|
||||
By default, all content is served from the root of your application (`/`).
|
||||
If you would rather map to a different path, you can configure one as follows:
|
||||
|
||||
[source,properties,indent=0,subs="verbatim",configprops]
|
||||
[source,yaml,indent=0,subs="verbatim",configprops,configblocks]
|
||||
----
|
||||
spring.mvc.servlet.path=/acme
|
||||
spring:
|
||||
mvc:
|
||||
servlet:
|
||||
path: "/acme"
|
||||
----
|
||||
|
||||
If you have additional servlets you can declare a `@Bean` of type `Servlet` or `ServletRegistrationBean` for each and Spring Boot will register them transparently to the container.
|
||||
@@ -1299,13 +1342,15 @@ If Logback is available, it is the first choice.
|
||||
|
||||
If the only change you need to make to logging is to set the levels of various loggers, you can do so in `application.properties` by using the "logging.level" prefix, as shown in the following example:
|
||||
|
||||
[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
|
||||
[source,yaml,indent=0,subs="verbatim,quotes,attributes",configprops,configblocks]
|
||||
----
|
||||
logging.level.org.springframework.web=DEBUG
|
||||
logging.level.org.hibernate=ERROR
|
||||
logging:
|
||||
level:
|
||||
org.springframework.web: "debug"
|
||||
org.hibernate: "error"
|
||||
----
|
||||
|
||||
You can also set the location of a file to which to write the log (in addition to the console) by using "logging.file.name".
|
||||
You can also set the location of a file to which to write the log (in addition to the console) by using `logging.file.name`.
|
||||
|
||||
To configure the more fine-grained settings of a logging system, you need to use the native configuration format supported by the `LoggingSystem` in question.
|
||||
By default, Spring Boot picks up the native configuration from its default location for the system (such as `classpath:logback.xml` for Logback), but you can set the location of the config file by using the configprop:logging.config[] property.
|
||||
@@ -1382,11 +1427,13 @@ If you want to disable console logging and write output only to a file, you need
|
||||
</configuration>
|
||||
----
|
||||
|
||||
You also need to add `logging.file.name` to your `application.properties`, as shown in the following example:
|
||||
You also need to add `logging.file.name` to your `application.properties` or `application.yaml`, as shown in the following example:
|
||||
|
||||
[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
|
||||
[source,yaml,indent=0,subs="verbatim,quotes,attributes",configprops,configblocks]
|
||||
----
|
||||
logging.file.name=myapplication.log
|
||||
logging:
|
||||
file:
|
||||
name: "myapplication.log"
|
||||
----
|
||||
|
||||
|
||||
@@ -1492,11 +1539,13 @@ The following example shows how to define a data source in a bean:
|
||||
|
||||
The following example shows how to define a data source by setting properties:
|
||||
|
||||
[source,properties,indent=0]
|
||||
[source,yaml,indent=0,configblocks]
|
||||
----
|
||||
app.datasource.url=jdbc:h2:mem:mydb
|
||||
app.datasource.username=sa
|
||||
app.datasource.pool-size=30
|
||||
app:
|
||||
datasource:
|
||||
url: "jdbc:h2:mem:mydb"
|
||||
username: "sa"
|
||||
pool-size: 30
|
||||
----
|
||||
|
||||
Assuming that your `FancyDataSource` has regular JavaBean properties for the URL, the username, and the pool size, these settings are bound automatically before the `DataSource` is made available to other components.
|
||||
@@ -1519,12 +1568,14 @@ Check the implementation that is going to be used at runtime for more details.
|
||||
|
||||
The following example shows how to define a JDBC data source by setting properties:
|
||||
|
||||
[source,properties,indent=0]
|
||||
[source,yaml,indent=0,configblocks]
|
||||
----
|
||||
app.datasource.url=jdbc:mysql://localhost/test
|
||||
app.datasource.username=dbuser
|
||||
app.datasource.password=dbpass
|
||||
app.datasource.pool-size=30
|
||||
app:
|
||||
datasource:
|
||||
url: "jdbc:mysql://localhost/test"
|
||||
username: "dbuser"
|
||||
password: "dbpass"
|
||||
pool-size: 30
|
||||
----
|
||||
|
||||
However, there is a catch.
|
||||
@@ -1532,12 +1583,14 @@ Because the actual type of the connection pool is not exposed, no keys are gener
|
||||
Also, if you happen to have Hikari on the classpath, this basic setup does not work, because Hikari has no `url` property (but does have a `jdbcUrl` property).
|
||||
In that case, you must rewrite your configuration as follows:
|
||||
|
||||
[source,properties,indent=0]
|
||||
[source,yaml,indent=0,configblocks]
|
||||
----
|
||||
app.datasource.jdbc-url=jdbc:mysql://localhost/test
|
||||
app.datasource.username=dbuser
|
||||
app.datasource.password=dbpass
|
||||
app.datasource.maximum-pool-size=30
|
||||
app:
|
||||
datasource:
|
||||
jdbc-url: "jdbc:mysql://localhost/test"
|
||||
username: "dbuser"
|
||||
password: "dbpass"
|
||||
pool-size: 30
|
||||
----
|
||||
|
||||
You can fix that by forcing the connection pool to use and return a dedicated implementation rather than `DataSource`.
|
||||
@@ -1563,12 +1616,15 @@ include::{code-examples}/jdbc/ConfigurableDataSourceExample.java[tag=configurati
|
||||
This setup puts you _in sync_ with what Spring Boot does for you by default, except that a dedicated connection pool is chosen (in code) and its settings are exposed in the `app.datasource.configuration` sub namespace.
|
||||
Because `DataSourceProperties` is taking care of the `url`/`jdbcUrl` translation for you, you can configure it as follows:
|
||||
|
||||
[source,properties,indent=0]
|
||||
[source,yaml,indent=0,configblocks]
|
||||
----
|
||||
app.datasource.url=jdbc:mysql://localhost/test
|
||||
app.datasource.username=dbuser
|
||||
app.datasource.password=dbpass
|
||||
app.datasource.configuration.maximum-pool-size=30
|
||||
app:
|
||||
datasource:
|
||||
url: "jdbc:mysql://localhost/test"
|
||||
username: "dbuser"
|
||||
password: "dbpass"
|
||||
configuration:
|
||||
maximum-pool-size: 30
|
||||
----
|
||||
|
||||
TIP: Spring Boot will expose Hikari-specific settings to `spring.datasource.hikari`.
|
||||
@@ -1599,17 +1655,22 @@ TIP: `firstDataSourceProperties` has to be flagged as `@Primary` so that the dat
|
||||
Both data sources are also bound for advanced customizations.
|
||||
For instance, you could configure them as follows:
|
||||
|
||||
[source,properties,indent=0]
|
||||
[source,yaml,indent=0,configblocks]
|
||||
----
|
||||
app.datasource.first.url=jdbc:mysql://localhost/first
|
||||
app.datasource.first.username=dbuser
|
||||
app.datasource.first.password=dbpass
|
||||
app.datasource.first.configuration.maximum-pool-size=30
|
||||
app:
|
||||
datasource:
|
||||
first:
|
||||
url: "jdbc:mysql://localhost/first"
|
||||
username: "dbuser"
|
||||
password: "dbpass"
|
||||
configuration:
|
||||
maximum-pool-size: 30
|
||||
|
||||
app.datasource.second.url=jdbc:mysql://localhost/second
|
||||
app.datasource.second.username=dbuser
|
||||
app.datasource.second.password=dbpass
|
||||
app.datasource.second.max-total=30
|
||||
second:
|
||||
url: "jdbc:mysql://localhost/second"
|
||||
username: "dbuser"
|
||||
password: "dbpass"
|
||||
max-total: 30
|
||||
----
|
||||
|
||||
You can apply the same concept to the secondary `DataSource` as well, as shown in the following example:
|
||||
@@ -1673,10 +1734,14 @@ If you prefer to set the dialect yourself, set the configprop:spring.jpa.databas
|
||||
|
||||
The most common options to set are shown in the following example:
|
||||
|
||||
[indent=0,subs="verbatim,quotes,attributes"]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
spring.jpa.hibernate.naming.physical-strategy=com.example.MyPhysicalNamingStrategy
|
||||
spring.jpa.show-sql=true
|
||||
spring:
|
||||
jpa:
|
||||
hibernate:
|
||||
naming:
|
||||
physical-strategy: "com.example.MyPhysicalNamingStrategy"
|
||||
show-sql: true
|
||||
----
|
||||
|
||||
In addition, all properties in `+spring.jpa.properties.*+` are passed through as normal JPA properties (with the prefix stripped) when the local `EntityManagerFactory` is created.
|
||||
@@ -1993,12 +2058,14 @@ Spring Boot can detect your database type and execute those scripts on startup.
|
||||
If you use an embedded database, this happens by default.
|
||||
You can also enable it for any database type, as shown in the following example:
|
||||
|
||||
[indent=0,subs="verbatim,quotes,attributes"]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
spring.batch.initialize-schema=always
|
||||
spring:
|
||||
batch:
|
||||
initialize-schema: "always"
|
||||
----
|
||||
|
||||
You can also switch off the initialization explicitly by setting `spring.batch.initialize-schema=never`.
|
||||
You can also switch off the initialization explicitly by setting `spring.batch.initialize-schema` to `never`.
|
||||
|
||||
|
||||
|
||||
@@ -2017,17 +2084,21 @@ By default, they are in a directory called `classpath:db/migration`, but you can
|
||||
This is a comma-separated list of one or more `classpath:` or `filesystem:` locations.
|
||||
For example, the following configuration would search for scripts in both the default classpath location and the `/opt/migration` directory:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
spring.flyway.locations=classpath:db/migration,filesystem:/opt/migration
|
||||
spring:
|
||||
flyway:
|
||||
locations: "classpath:db/migration,filesystem:/opt/migration"
|
||||
----
|
||||
|
||||
You can also add a special `\{vendor}` placeholder to use vendor-specific scripts.
|
||||
Assume the following:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
spring.flyway.locations=classpath:db/migration/{vendor}
|
||||
spring:
|
||||
flyway:
|
||||
locations: "classpath:db/migration/{vendor}"
|
||||
----
|
||||
|
||||
Rather than using `db/migration`, the preceding configuration sets the directory to use according to the type of the database (such as `db/migration/mysql` for MySQL).
|
||||
@@ -2061,9 +2132,11 @@ For example, you can place test-specific migrations in `src/test/resources` and
|
||||
Also, you can use profile-specific configuration to customize `spring.flyway.locations` so that certain migrations run only when a particular profile is active.
|
||||
For example, in `application-dev.properties`, you might specify the following setting:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
spring.flyway.locations=classpath:/db/migration,classpath:/dev/db/migration
|
||||
spring:
|
||||
flyway:
|
||||
locations: "classpath:/db/migration,classpath:/dev/db/migration"
|
||||
----
|
||||
|
||||
With that setup, migrations in `dev/db/migration` run only when the `dev` profile is active.
|
||||
@@ -2287,10 +2360,13 @@ If you use Tomcat as a servlet container, then Spring Boot adds Tomcat's own `Re
|
||||
The standard behavior is determined by the presence or absence of certain request headers (`x-forwarded-for` and `x-forwarded-proto`), whose names are conventional, so it should work with most front-end proxies.
|
||||
You can switch on the valve by adding some entries to `application.properties`, as shown in the following example:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
server.tomcat.remoteip.remote-ip-header=x-forwarded-for
|
||||
server.tomcat.remoteip.protocol-header=x-forwarded-proto
|
||||
server:
|
||||
tomcat:
|
||||
remoteip:
|
||||
remote-ip-header: "x-forwarded-for"
|
||||
protocol-header: "x-forwarded-proto"
|
||||
----
|
||||
|
||||
(The presence of either of those properties switches on the valve.
|
||||
|
||||
@@ -161,18 +161,25 @@ By default, all endpoints except for `shutdown` are enabled.
|
||||
To configure the enablement of an endpoint, use its `management.endpoint.<id>.enabled` property.
|
||||
The following example enables the `shutdown` endpoint:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.endpoint.shutdown.enabled=true
|
||||
management:
|
||||
endpoint:
|
||||
shutdown:
|
||||
enabled: true
|
||||
----
|
||||
|
||||
If you prefer endpoint enablement to be opt-in rather than opt-out, set the configprop:management.endpoints.enabled-by-default[] property to `false` and use individual endpoint `enabled` properties to opt back in.
|
||||
The following example enables the `info` endpoint and disables all other endpoints:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.endpoints.enabled-by-default=false
|
||||
management.endpoint.info.enabled=true
|
||||
management:
|
||||
endpoints:
|
||||
enabled-by-default: false
|
||||
endpoint:
|
||||
info:
|
||||
enabled: true
|
||||
----
|
||||
|
||||
NOTE: Disabled endpoints are removed entirely from the application context.
|
||||
@@ -312,33 +319,29 @@ Both `include` and `exclude` properties can be configured with a list of endpoin
|
||||
|
||||
For example, to stop exposing all endpoints over JMX and only expose the `health` and `info` endpoints, use the following property:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.endpoints.jmx.exposure.include=health,info
|
||||
management:
|
||||
endpoints:
|
||||
jmx:
|
||||
exposure:
|
||||
include: "health,info"
|
||||
----
|
||||
|
||||
`*` can be used to select all endpoints.
|
||||
For example, to expose everything over HTTP except the `env` and `beans` endpoints, use the following properties:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.endpoints.web.exposure.include=*
|
||||
management.endpoints.web.exposure.exclude=env,beans
|
||||
----
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
`*` has a special meaning in YAML, so be sure to add quotes if you want to include (or exclude) all endpoints, as shown in the following example:
|
||||
|
||||
[source,yaml,indent=0]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management:
|
||||
endpoints:
|
||||
web:
|
||||
exposure:
|
||||
include: "*"
|
||||
exclude: "env,beans"
|
||||
----
|
||||
====
|
||||
|
||||
NOTE: `*` has a special meaning in YAML, so be sure to add quotes if you want to include (or exclude) all endpoints.
|
||||
|
||||
NOTE: If your application is exposed publicly, we strongly recommend that you also <<production-ready-endpoints-security, secure your endpoints>>.
|
||||
|
||||
@@ -377,9 +380,13 @@ If you deploy applications behind a firewall, you may prefer that all your actua
|
||||
You can do so by changing the configprop:management.endpoints.web.exposure.include[] property, as follows:
|
||||
|
||||
.application.properties
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.endpoints.web.exposure.include=*
|
||||
management:
|
||||
endpoints:
|
||||
web:
|
||||
exposure:
|
||||
include: "*"
|
||||
----
|
||||
|
||||
Additionally, if Spring Security is present, you would need to add custom security configuration that allows unauthenticated access to the endpoints as shown in the following example:
|
||||
@@ -407,9 +414,13 @@ To configure the amount of time for which an endpoint will cache a response, use
|
||||
The following example sets the time-to-live of the `beans` endpoint's cache to 10 seconds:
|
||||
|
||||
.application.properties
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.endpoint.beans.cache.time-to-live=10s
|
||||
management:
|
||||
endpoint:
|
||||
beans:
|
||||
cache:
|
||||
time-to-live: "10s"
|
||||
----
|
||||
|
||||
NOTE: The prefix `management.endpoint.<name>` is used to uniquely identify the endpoint that is being configured.
|
||||
@@ -435,10 +446,14 @@ If you use Spring MVC or Spring WebFlux, Actuator's web endpoints can be configu
|
||||
CORS support is disabled by default and is only enabled once the configprop:management.endpoints.web.cors.allowed-origins[] property has been set.
|
||||
The following configuration permits `GET` and `POST` calls from the `example.com` domain:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.endpoints.web.cors.allowed-origins=https://example.com
|
||||
management.endpoints.web.cors.allowed-methods=GET,POST
|
||||
management:
|
||||
endpoints:
|
||||
web:
|
||||
cors:
|
||||
allowed-origins: "https://example.com"
|
||||
allowed-methods: "GET,POST"
|
||||
----
|
||||
|
||||
TIP: See {spring-boot-actuator-autoconfigure-module-code}/endpoint/web/CorsEndpointProperties.java[CorsEndpointProperties] for a complete list of options.
|
||||
@@ -798,9 +813,13 @@ In such cases, a custom implementation of the {spring-boot-actuator-module-code}
|
||||
For example, assume a new `Status` with code `FATAL` is being used in one of your `HealthIndicator` implementations.
|
||||
To configure the severity order, add the following property to your application properties:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.endpoint.health.status.order=fatal,down,out-of-service,unknown,up
|
||||
management:
|
||||
endpoint:
|
||||
health:
|
||||
status:
|
||||
order: "fatal,down,out-of-service,unknown,up"
|
||||
----
|
||||
|
||||
The HTTP status code in the response reflects the overall health status.
|
||||
@@ -811,11 +830,16 @@ Configuring a custom mapping disables the defaults mappings for `DOWN` and `OUT_
|
||||
If you want to retain the default mappings they must be configured explicitly alongside any custom mappings.
|
||||
For example, the following property maps `FATAL` to 503 (service unavailable) and retains the default mappings for `DOWN` and `OUT_OF_SERVICE`:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.endpoint.health.status.http-mapping.down=503
|
||||
management.endpoint.health.status.http-mapping.fatal=503
|
||||
management.endpoint.health.status.http-mapping.out-of-service=503
|
||||
management:
|
||||
endpoint:
|
||||
health:
|
||||
status:
|
||||
http-mapping:
|
||||
down: 503
|
||||
fatal: 503
|
||||
out-of-service: 503
|
||||
----
|
||||
|
||||
TIP: If you need more control, you can define your own `HttpCodeStatusMapper` bean.
|
||||
@@ -908,30 +932,47 @@ It's sometimes useful to organize health indicators into groups that can be used
|
||||
To create a health indicator group you can use the `management.endpoint.health.group.<name>` property and specify a list of health indicator IDs to `include` or `exclude`.
|
||||
For example, to create a group that includes only database indicators you can define the following:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.endpoint.health.group.custom.include=db
|
||||
management:
|
||||
endpoint:
|
||||
health:
|
||||
group:
|
||||
custom:
|
||||
include: "db"
|
||||
----
|
||||
|
||||
You can then check the result by hitting `http://localhost:8080/actuator/health/custom`.
|
||||
|
||||
Similarly, to create a group that excludes the database indicators from the group and includes all the other indicators, you can define the following:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.endpoint.health.group.custom.exclude=db
|
||||
management:
|
||||
endpoint:
|
||||
health:
|
||||
group:
|
||||
custom:
|
||||
exclude: "db"
|
||||
----
|
||||
|
||||
By default groups will inherit the same `StatusAggregator` and `HttpCodeStatusMapper` settings as the system health, however, these can also be defined on a per-group basis.
|
||||
It's also possible to override the `show-details` and `roles` properties if required:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.endpoint.health.group.custom.show-details=when-authorized
|
||||
management.endpoint.health.group.custom.roles=admin
|
||||
management.endpoint.health.group.custom.status.order=fatal,up
|
||||
management.endpoint.health.group.custom.status.http-mapping.fatal=500
|
||||
management.endpoint.health.group.custom.status.http-mapping.out-of-service=500
|
||||
management:
|
||||
endpoint:
|
||||
health:
|
||||
group:
|
||||
custom:
|
||||
show-details: "when-authorized"
|
||||
roles: "admin"
|
||||
status:
|
||||
order: "fatal,up"
|
||||
http-mapping:
|
||||
fatal: 500
|
||||
out-of-service: 500
|
||||
----
|
||||
|
||||
TIP: You can use `@Qualifier("groupname")` if you need to register custom `StatusAggregator` or `HttpCodeStatusMapper` beans for use with the group.
|
||||
@@ -986,9 +1027,14 @@ In this case, a probe check could be successful even if the main application doe
|
||||
Actuator configures the "liveness" and "readiness" probes as Health Groups; this means that all the <<production-ready-health-groups, Health Groups features>> are available for them.
|
||||
You can, for example, configure additional Health Indicators:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.endpoint.health.group.readiness.include=readinessState,customCheck
|
||||
management:
|
||||
endpoint:
|
||||
health:
|
||||
group:
|
||||
readiness:
|
||||
include: "readinessState,customCheck"
|
||||
----
|
||||
|
||||
By default, Spring Boot does not add other Health Indicators to these groups.
|
||||
@@ -1101,11 +1147,14 @@ You can customize the data exposed by the `info` endpoint by setting `+info.*+`
|
||||
All `Environment` properties under the `info` key are automatically exposed.
|
||||
For example, you could add the following settings to your `application.properties` file:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
info.app.encoding=UTF-8
|
||||
info.app.java.source=1.8
|
||||
info.app.java.target=1.8
|
||||
info:
|
||||
app:
|
||||
encoding: "UTF-8"
|
||||
java:
|
||||
source: "11"
|
||||
target: "11"
|
||||
----
|
||||
|
||||
[TIP]
|
||||
@@ -1114,11 +1163,14 @@ Rather than hardcoding those values, you could also <<howto.adoc#howto-automatic
|
||||
|
||||
Assuming you use Maven, you could rewrite the preceding example as follows:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
info.app.encoding=@project.build.sourceEncoding@
|
||||
info.app.java.source=@java.version@
|
||||
info.app.java.target=@java.version@
|
||||
info:
|
||||
app:
|
||||
encoding: "@project.build.sourceEncoding@"
|
||||
java:
|
||||
source: "@java.version@"
|
||||
target: "@java.version@"
|
||||
----
|
||||
====
|
||||
|
||||
@@ -1134,9 +1186,12 @@ See "<<howto.adoc#howto-git-info,Generate git information>>" for more details.
|
||||
|
||||
If you want to display the full git information (that is, the full content of `git.properties`), use the configprop:management.info.git.mode[] property, as follows:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.info.git.mode=full
|
||||
management:
|
||||
info:
|
||||
git:
|
||||
mode: "full"
|
||||
----
|
||||
|
||||
|
||||
@@ -1209,9 +1264,12 @@ Sometimes, it is useful to customize the prefix for the management endpoints.
|
||||
For example, your application might already use `/actuator` for another purpose.
|
||||
You can use the configprop:management.endpoints.web.base-path[] property to change the prefix for your management endpoint, as shown in the following example:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.endpoints.web.base-path=/manage
|
||||
management:
|
||||
endpoints:
|
||||
web:
|
||||
base-path: "/manage"
|
||||
----
|
||||
|
||||
The preceding `application.properties` example changes the endpoint from `/actuator/\{id}` to `/manage/\{id}` (for example, `/manage/info`).
|
||||
@@ -1224,10 +1282,14 @@ If you want to map endpoints to a different path, you can use the configprop:man
|
||||
The following example remaps `/actuator/health` to `/healthcheck`:
|
||||
|
||||
.application.properties
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.endpoints.web.base-path=/
|
||||
management.endpoints.web.path-mapping.health=healthcheck
|
||||
management:
|
||||
endpoints:
|
||||
web:
|
||||
base-path: "/"
|
||||
path-mapping:
|
||||
health: "healthcheck"
|
||||
----
|
||||
|
||||
|
||||
@@ -1239,9 +1301,11 @@ If, however, your application runs inside your own data center, you may prefer t
|
||||
|
||||
You can set the configprop:management.server.port[] property to change the HTTP port, as shown in the following example:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.server.port=8081
|
||||
management:
|
||||
server:
|
||||
port: 8081
|
||||
----
|
||||
|
||||
NOTE: On Cloud Foundry, applications only receive requests on port 8080 for both HTTP and TCP routing, by default.
|
||||
@@ -1254,28 +1318,38 @@ If you want to use a custom management port on Cloud Foundry, you will need to e
|
||||
When configured to use a custom port, the management server can also be configured with its own SSL by using the various `management.server.ssl.*` properties.
|
||||
For example, doing so lets a management server be available over HTTP while the main application uses HTTPS, as shown in the following property settings:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
server.port=8443
|
||||
server.ssl.enabled=true
|
||||
server.ssl.key-store=classpath:store.jks
|
||||
server.ssl.key-password=secret
|
||||
management.server.port=8080
|
||||
management.server.ssl.enabled=false
|
||||
server:
|
||||
port: 8443
|
||||
ssl:
|
||||
enabled: true
|
||||
key-store: "classpath:store.jks"
|
||||
key-password: secret
|
||||
management:
|
||||
server:
|
||||
port: 8080
|
||||
ssl:
|
||||
enabled: false
|
||||
----
|
||||
|
||||
Alternatively, both the main server and the management server can use SSL but with different key stores, as follows:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
server.port=8443
|
||||
server.ssl.enabled=true
|
||||
server.ssl.key-store=classpath:main.jks
|
||||
server.ssl.key-password=secret
|
||||
management.server.port=8080
|
||||
management.server.ssl.enabled=true
|
||||
management.server.ssl.key-store=classpath:management.jks
|
||||
management.server.ssl.key-password=secret
|
||||
server:
|
||||
port: 8443
|
||||
ssl:
|
||||
enabled: true
|
||||
key-store: "classpath:main.jks"
|
||||
key-password: "secret"
|
||||
management:
|
||||
server:
|
||||
port: 8080
|
||||
ssl:
|
||||
enabled: true
|
||||
key-store: "classpath:management.jks"
|
||||
key-password: "secret"
|
||||
----
|
||||
|
||||
|
||||
@@ -1289,10 +1363,12 @@ NOTE: You can listen on a different address only when the port differs from the
|
||||
|
||||
The following example `application.properties` does not allow remote management connections:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.server.port=8081
|
||||
management.server.address=127.0.0.1
|
||||
management:
|
||||
server:
|
||||
port: 8081
|
||||
address: "127.0.0.1"
|
||||
----
|
||||
|
||||
|
||||
@@ -1301,16 +1377,22 @@ The following example `application.properties` does not allow remote management
|
||||
=== Disabling HTTP Endpoints
|
||||
If you do not want to expose endpoints over HTTP, you can set the management port to `-1`, as shown in the following example:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.server.port=-1
|
||||
management:
|
||||
server:
|
||||
port: -1
|
||||
----
|
||||
|
||||
This can be achieved using the configprop:management.endpoints.web.exposure.exclude[] property as well, as shown in the following example:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.endpoints.web.exposure.exclude=*
|
||||
management:
|
||||
endpoints:
|
||||
web:
|
||||
exposure:
|
||||
exclude: "*"
|
||||
----
|
||||
|
||||
|
||||
@@ -1334,10 +1416,15 @@ To solve this problem, you can set the configprop:spring.jmx.unique-names[] prop
|
||||
You can also customize the JMX domain under which endpoints are exposed.
|
||||
The following settings show an example of doing so in `application.properties`:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
spring.jmx.unique-names=true
|
||||
management.endpoints.jmx.domain=com.example.myapp
|
||||
spring:
|
||||
jmx:
|
||||
unique-names: true
|
||||
management:
|
||||
endpoints:
|
||||
jmx:
|
||||
domain: "com.example.myapp"
|
||||
----
|
||||
|
||||
|
||||
@@ -1346,9 +1433,13 @@ The following settings show an example of doing so in `application.properties`:
|
||||
=== Disabling JMX Endpoints
|
||||
If you do not want to expose endpoints over JMX, you can set the configprop:management.endpoints.jmx.exposure.exclude[] property to `*`, as shown in the following example:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.endpoints.jmx.exposure.exclude=*
|
||||
management:
|
||||
endpoints:
|
||||
jmx:
|
||||
exposure:
|
||||
exclude: "*"
|
||||
----
|
||||
|
||||
|
||||
@@ -1382,9 +1473,13 @@ Jolokia has a number of settings that you would traditionally configure by setti
|
||||
With Spring Boot, you can use your `application.properties` file.
|
||||
To do so, prefix the parameter with `management.endpoint.jolokia.config.`, as shown in the following example:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.endpoint.jolokia.config.debug=true
|
||||
management:
|
||||
endpoint:
|
||||
jolokia:
|
||||
config:
|
||||
debug: true
|
||||
----
|
||||
|
||||
|
||||
@@ -1393,9 +1488,12 @@ To do so, prefix the parameter with `management.endpoint.jolokia.config.`, as sh
|
||||
==== Disabling Jolokia
|
||||
If you use Jolokia but do not want Spring Boot to configure it, set the configprop:management.endpoint.jolokia.enabled[] property to `false`, as follows:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.endpoint.jolokia.enabled=false
|
||||
management:
|
||||
endpoint:
|
||||
jolokia:
|
||||
enabled: false
|
||||
----
|
||||
|
||||
|
||||
@@ -1470,23 +1568,33 @@ Most registries share common features.
|
||||
For instance, you can disable a particular registry even if the Micrometer registry implementation is on the classpath.
|
||||
For example, to disable Datadog:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.metrics.export.datadog.enabled=false
|
||||
management:
|
||||
metrics:
|
||||
export:
|
||||
datadog:
|
||||
enabled: false
|
||||
----
|
||||
|
||||
You can also disable all registries unless stated otherwise by the registry-specific property, as shown in the following example:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.metrics.export.defaults.enabled=false
|
||||
management:
|
||||
metrics:
|
||||
export:
|
||||
defaults:
|
||||
enabled: false
|
||||
----
|
||||
|
||||
Spring Boot will also add any auto-configured registries to the global static composite registry on the `Metrics` class unless you explicitly tell it not to:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.metrics.use-global-registry=false
|
||||
management:
|
||||
metrics:
|
||||
use-global-registry: false
|
||||
----
|
||||
|
||||
You can register any number of `MeterRegistryCustomizer` beans to further configure the registry, such as applying common tags, before any meters are registered with the registry:
|
||||
@@ -1523,9 +1631,13 @@ Spring Boot also <<production-ready-metrics-meter,configures built-in instrument
|
||||
By default, the AppOptics registry pushes metrics to `https://api.appoptics.com/v1/measurements` periodically.
|
||||
To export metrics to SaaS {micrometer-registry-docs}/appOptics[AppOptics], your API token must be provided:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.metrics.export.appoptics.api-token=YOUR_TOKEN
|
||||
management:
|
||||
metrics:
|
||||
export:
|
||||
appoptics:
|
||||
api-token: "YOUR_TOKEN"
|
||||
----
|
||||
|
||||
|
||||
@@ -1535,9 +1647,13 @@ To export metrics to SaaS {micrometer-registry-docs}/appOptics[AppOptics], your
|
||||
By default, metrics are exported to {micrometer-registry-docs}/atlas[Atlas] running on your local machine.
|
||||
The location of the https://github.com/Netflix/atlas[Atlas server] to use can be provided using:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.metrics.export.atlas.uri=https://atlas.example.com:7101/api/v1/publish
|
||||
management:
|
||||
metrics:
|
||||
export:
|
||||
atlas:
|
||||
uri: "https://atlas.example.com:7101/api/v1/publish"
|
||||
----
|
||||
|
||||
|
||||
@@ -1547,16 +1663,24 @@ The location of the https://github.com/Netflix/atlas[Atlas server] to use can be
|
||||
Datadog registry pushes metrics to https://www.datadoghq.com[datadoghq] periodically.
|
||||
To export metrics to {micrometer-registry-docs}/datadog[Datadog], your API key must be provided:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.metrics.export.datadog.api-key=YOUR_KEY
|
||||
management:
|
||||
metrics:
|
||||
export:
|
||||
datadog:
|
||||
api-key: "YOUR_KEY"
|
||||
----
|
||||
|
||||
You can also change the interval at which metrics are sent to Datadog:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.metrics.export.datadog.step=30s
|
||||
management:
|
||||
metrics:
|
||||
export:
|
||||
datadog:
|
||||
step: "30s"
|
||||
----
|
||||
|
||||
|
||||
@@ -1566,18 +1690,26 @@ You can also change the interval at which metrics are sent to Datadog:
|
||||
Dynatrace registry pushes metrics to the configured URI periodically.
|
||||
To export metrics to {micrometer-registry-docs}/dynatrace[Dynatrace], your API token, device ID, and URI must be provided:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.metrics.export.dynatrace.api-token=YOUR_TOKEN
|
||||
management.metrics.export.dynatrace.device-id=YOUR_DEVICE_ID
|
||||
management.metrics.export.dynatrace.uri=YOUR_URI
|
||||
management:
|
||||
metrics:
|
||||
export:
|
||||
dynatrace:
|
||||
api-token: "YOUR_TOKEN"
|
||||
device-id: "YOUR_DEVICE_ID"
|
||||
uri: "YOUR_URI"
|
||||
----
|
||||
|
||||
You can also change the interval at which metrics are sent to Dynatrace:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.metrics.export.dynatrace.step=30s
|
||||
management:
|
||||
metrics:
|
||||
export:
|
||||
dynatrace:
|
||||
step: "30s"
|
||||
----
|
||||
|
||||
|
||||
@@ -1587,9 +1719,13 @@ You can also change the interval at which metrics are sent to Dynatrace:
|
||||
By default, metrics are exported to {micrometer-registry-docs}/elastic[Elastic] running on your local machine.
|
||||
The location of the Elastic server to use can be provided using the following property:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.metrics.export.elastic.host=https://elastic.example.com:8086
|
||||
management:
|
||||
metrics:
|
||||
export:
|
||||
elastic:
|
||||
host: "https://elastic.example.com:8086"
|
||||
----
|
||||
|
||||
|
||||
@@ -1599,10 +1735,14 @@ The location of the Elastic server to use can be provided using the following pr
|
||||
By default, metrics are exported to {micrometer-registry-docs}/ganglia[Ganglia] running on your local machine.
|
||||
The http://ganglia.sourceforge.net[Ganglia server] host and port to use can be provided using:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.metrics.export.ganglia.host=ganglia.example.com
|
||||
management.metrics.export.ganglia.port=9649
|
||||
management:
|
||||
metrics:
|
||||
export:
|
||||
ganglia:
|
||||
host: "ganglia.example.com"
|
||||
port: 9649
|
||||
----
|
||||
|
||||
|
||||
@@ -1612,10 +1752,14 @@ The http://ganglia.sourceforge.net[Ganglia server] host and port to use can be p
|
||||
By default, metrics are exported to {micrometer-registry-docs}/graphite[Graphite] running on your local machine.
|
||||
The https://graphiteapp.org[Graphite server] host and port to use can be provided using:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.metrics.export.graphite.host=graphite.example.com
|
||||
management.metrics.export.graphite.port=9004
|
||||
management:
|
||||
metrics:
|
||||
export:
|
||||
graphite:
|
||||
host: "graphite.example.com"
|
||||
port: 9004
|
||||
----
|
||||
|
||||
Micrometer provides a default `HierarchicalNameMapper` that governs how a dimensional meter id is {micrometer-registry-docs}/graphite#_hierarchical_name_mapping[mapped to flat hierarchical names].
|
||||
@@ -1638,17 +1782,26 @@ public GraphiteMeterRegistry graphiteMeterRegistry(GraphiteConfig config, Clock
|
||||
By default, the Humio registry pushes metrics to https://cloud.humio.com periodically.
|
||||
To export metrics to SaaS {micrometer-registry-docs}/humio[Humio], your API token must be provided:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.metrics.export.humio.api-token=YOUR_TOKEN
|
||||
management:
|
||||
metrics:
|
||||
export:
|
||||
humio:
|
||||
api-token: "YOUR_TOKEN"
|
||||
----
|
||||
|
||||
You should also configure one or more tags to identify the data source to which metrics will be pushed:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.metrics.export.humio.tags.alpha=a
|
||||
management.metrics.export.humio.tags.bravo=b
|
||||
management:
|
||||
metrics:
|
||||
export:
|
||||
humio:
|
||||
tags:
|
||||
alpha: "a"
|
||||
bravo: "b"
|
||||
----
|
||||
|
||||
|
||||
@@ -1658,9 +1811,13 @@ You should also configure one or more tags to identify the data source to which
|
||||
By default, metrics are exported to {micrometer-registry-docs}/influx[Influx] running on your local machine.
|
||||
The location of the https://www.influxdata.com[Influx server] to use can be provided using:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.metrics.export.influx.uri=https://influx.example.com:8086
|
||||
management:
|
||||
metrics:
|
||||
export:
|
||||
influx:
|
||||
uri: "https://influx.example.com:8086"
|
||||
----
|
||||
|
||||
|
||||
@@ -1671,9 +1828,13 @@ Micrometer provides a hierarchical mapping to {micrometer-registry-docs}/jmx[JMX
|
||||
By default, metrics are exported to the `metrics` JMX domain.
|
||||
The domain to use can be provided using:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.metrics.export.jmx.domain=com.example.app.metrics
|
||||
management:
|
||||
metrics:
|
||||
export:
|
||||
jmx:
|
||||
domain: "com.example.app.metrics"
|
||||
----
|
||||
|
||||
Micrometer provides a default `HierarchicalNameMapper` that governs how a dimensional meter id is {micrometer-registry-docs}/jmx#_hierarchical_name_mapping[mapped to flat hierarchical names].
|
||||
@@ -1696,9 +1857,13 @@ public JmxMeterRegistry jmxMeterRegistry(JmxConfig config, Clock clock) {
|
||||
By default, metrics are exported to {micrometer-registry-docs}/kairos[KairosDB] running on your local machine.
|
||||
The location of the https://kairosdb.github.io/[KairosDB server] to use can be provided using:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.metrics.export.kairos.uri=https://kairosdb.example.com:8080/api/v1/datapoints
|
||||
management:
|
||||
metrics:
|
||||
export:
|
||||
kairos:
|
||||
uri: "https://kairosdb.example.com:8080/api/v1/datapoints"
|
||||
----
|
||||
|
||||
|
||||
@@ -1708,24 +1873,36 @@ The location of the https://kairosdb.github.io/[KairosDB server] to use can be p
|
||||
New Relic registry pushes metrics to {micrometer-registry-docs}/new-relic[New Relic] periodically.
|
||||
To export metrics to https://newrelic.com[New Relic], your API key and account id must be provided:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.metrics.export.newrelic.api-key=YOUR_KEY
|
||||
management.metrics.export.newrelic.account-id=YOUR_ACCOUNT_ID
|
||||
management:
|
||||
metrics:
|
||||
export:
|
||||
newrelic:
|
||||
api-key: "YOUR_KEY"
|
||||
account-id: "YOUR_ACCOUNT_ID"
|
||||
----
|
||||
|
||||
You can also change the interval at which metrics are sent to New Relic:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.metrics.export.newrelic.step=30s
|
||||
management:
|
||||
metrics:
|
||||
export:
|
||||
newrelic:
|
||||
step: "30s"
|
||||
----
|
||||
|
||||
By default, metrics are published via REST calls but it is also possible to use the Java Agent API if you have it on the classpath:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.metrics.export.newrelic.client-provider-type=insights-agent
|
||||
management:
|
||||
metrics:
|
||||
export:
|
||||
newrelic:
|
||||
client-provider-type: "insights-agent"
|
||||
----
|
||||
|
||||
Finally, you can take full control by defining your own `NewRelicClientProvider` bean.
|
||||
@@ -1774,16 +1951,24 @@ For advanced configuration, you can also provide your own `PrometheusPushGateway
|
||||
SignalFx registry pushes metrics to {micrometer-registry-docs}/signalFx[SignalFx] periodically.
|
||||
To export metrics to https://www.signalfx.com[SignalFx], your access token must be provided:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.metrics.export.signalfx.access-token=YOUR_ACCESS_TOKEN
|
||||
management:
|
||||
metrics:
|
||||
export:
|
||||
signalfx:
|
||||
access-token: "YOUR_ACCESS_TOKEN"
|
||||
----
|
||||
|
||||
You can also change the interval at which metrics are sent to SignalFx:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.metrics.export.signalfx.step=30s
|
||||
management:
|
||||
metrics:
|
||||
export:
|
||||
signalfx:
|
||||
step: "30s"
|
||||
----
|
||||
|
||||
|
||||
@@ -1796,9 +1981,13 @@ This allows you to see what metrics are collected in the <<production-ready-metr
|
||||
The in-memory backend disables itself as soon as you're using any of the other available backend.
|
||||
You can also disable it explicitly:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.metrics.export.simple.enabled=false
|
||||
management:
|
||||
metrics:
|
||||
export:
|
||||
simple:
|
||||
enabled: false
|
||||
----
|
||||
|
||||
|
||||
@@ -1808,16 +1997,24 @@ You can also disable it explicitly:
|
||||
Stackdriver registry pushes metrics to https://cloud.google.com/stackdriver/[Stackdriver] periodically.
|
||||
To export metrics to SaaS {micrometer-registry-docs}/stackdriver[Stackdriver], your Google Cloud project id must be provided:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.metrics.export.stackdriver.project-id=my-project
|
||||
management:
|
||||
metrics:
|
||||
export:
|
||||
stackdriver:
|
||||
project-id: "my-project"
|
||||
----
|
||||
|
||||
You can also change the interval at which metrics are sent to Stackdriver:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.metrics.export.stackdriver.step=30s
|
||||
management:
|
||||
metrics:
|
||||
export:
|
||||
stackdriver:
|
||||
step: "30s"
|
||||
----
|
||||
|
||||
|
||||
@@ -1828,18 +2025,26 @@ The StatsD registry pushes metrics over UDP to a StatsD agent eagerly.
|
||||
By default, metrics are exported to a {micrometer-registry-docs}/statsD[StatsD] agent running on your local machine.
|
||||
The StatsD agent host, port, and protocol to use can be provided using:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.metrics.export.statsd.host=statsd.example.com
|
||||
management.metrics.export.statsd.port=9125
|
||||
management.metrics.export.statsd.protocol=udp
|
||||
management:
|
||||
metrics:
|
||||
export:
|
||||
statsd:
|
||||
host: "statsd.example.com"
|
||||
port: 9125
|
||||
protocol: "udp"
|
||||
----
|
||||
|
||||
You can also change the StatsD line protocol to use (default to Datadog):
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.metrics.export.statsd.flavor=etsy
|
||||
management:
|
||||
metrics:
|
||||
export:
|
||||
statsd:
|
||||
flavor: "etsy"
|
||||
----
|
||||
|
||||
|
||||
@@ -1849,25 +2054,37 @@ You can also change the StatsD line protocol to use (default to Datadog):
|
||||
Wavefront registry pushes metrics to {micrometer-registry-docs}/wavefront[Wavefront] periodically.
|
||||
If you are exporting metrics to https://www.wavefront.com/[Wavefront] directly, your API token must be provided:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.metrics.export.wavefront.api-token=YOUR_API_TOKEN
|
||||
management:
|
||||
metrics:
|
||||
export:
|
||||
wavefront:
|
||||
api-token: "YOUR_API_TOKEN"
|
||||
----
|
||||
|
||||
Alternatively, you may use a Wavefront sidecar or an internal proxy set up in your environment that forwards metrics data to the Wavefront API host:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.metrics.export.wavefront.uri=proxy://localhost:2878
|
||||
management:
|
||||
metrics:
|
||||
export:
|
||||
wavefront:
|
||||
uri: "proxy://localhost:2878"
|
||||
----
|
||||
|
||||
TIP: If publishing metrics to a Wavefront proxy (as described in https://docs.wavefront.com/proxies_installing.html[the documentation]), the host must be in the `proxy://HOST:PORT` format.
|
||||
|
||||
You can also change the interval at which metrics are sent to Wavefront:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.metrics.export.wavefront.step=30s
|
||||
management:
|
||||
metrics:
|
||||
export:
|
||||
wavefront:
|
||||
step: "30s"
|
||||
----
|
||||
|
||||
|
||||
@@ -2119,9 +2336,12 @@ Metrics are also tagged by the name of the `EntityManagerFactory` that is derive
|
||||
To enable statistics, the standard JPA property `hibernate.generate_statistics` must be set to `true`.
|
||||
You can enable that on the auto-configured `EntityManagerFactory` as shown in the following example:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
spring.jpa.properties.hibernate.generate_statistics=true
|
||||
spring:
|
||||
jpa:
|
||||
properties:
|
||||
"[hibernate.generate_statistics]": true
|
||||
----
|
||||
|
||||
|
||||
@@ -2180,10 +2400,13 @@ include::{code-examples}/actuate/metrics/MetricsFilterBeanExample.java[tag=confi
|
||||
Common tags are generally used for dimensional drill-down on the operating environment like host, instance, region, stack, etc.
|
||||
Commons tags are applied to all meters and can be configured as shown in the following example:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.metrics.tags.region=us-east-1
|
||||
management.metrics.tags.stack=prod
|
||||
management:
|
||||
metrics:
|
||||
tags:
|
||||
region: "us-east-1"
|
||||
stack: "prod"
|
||||
----
|
||||
|
||||
The example above adds `region` and `stack` tags to all meters with a value of `us-east-1` and `prod` respectively.
|
||||
@@ -2198,9 +2421,13 @@ In addition to `MeterFilter` beans, it's also possible to apply a limited set of
|
||||
Per-meter customizations apply to any all meter IDs that start with the given name.
|
||||
For example, the following will disable any meters that have an ID starting with `example.remote`
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.metrics.enable.example.remote=false
|
||||
management:
|
||||
metrics:
|
||||
enable:
|
||||
example:
|
||||
remote: false
|
||||
----
|
||||
|
||||
The following properties allow per-meter customization:
|
||||
@@ -2347,9 +2574,11 @@ If you want to fully disable the `/cloudfoundryapplication` endpoints, you can a
|
||||
|
||||
|
||||
.application.properties
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.cloudfoundry.enabled=false
|
||||
management:
|
||||
cloudfoundry:
|
||||
enabled: false
|
||||
----
|
||||
|
||||
|
||||
@@ -2360,9 +2589,11 @@ By default, the security verification for `/cloudfoundryapplication` endpoints m
|
||||
If your Cloud Foundry UAA or Cloud Controller services use self-signed certificates, you need to set the following property:
|
||||
|
||||
.application.properties
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
management.cloudfoundry.skip-ssl-validation=true
|
||||
management:
|
||||
cloudfoundry:
|
||||
skip-ssl-validation: true
|
||||
----
|
||||
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -630,9 +630,12 @@ The report shows the changes to your application's auto-configuration as you mak
|
||||
|
||||
To disable the logging of the report, set the following property:
|
||||
|
||||
[indent=0]
|
||||
[source,yaml,indent=0,configblocks]
|
||||
----
|
||||
spring.devtools.restart.log-condition-evaluation-delta=false
|
||||
spring:
|
||||
devtools:
|
||||
restart:
|
||||
log-condition-evaluation-delta: false
|
||||
----
|
||||
|
||||
|
||||
@@ -644,9 +647,12 @@ By default, changing resources in `/META-INF/maven`, `/META-INF/resources`, `/re
|
||||
If you want to customize these exclusions, you can use the configprop:spring.devtools.restart.exclude[] property.
|
||||
For example, to exclude only `/static` and `/public` you would set the following property:
|
||||
|
||||
[indent=0]
|
||||
[source,yaml,indent=0,configblocks]
|
||||
----
|
||||
spring.devtools.restart.exclude=static/**,public/**
|
||||
spring:
|
||||
devtools:
|
||||
restart:
|
||||
exclude: "static/**,public/**"
|
||||
----
|
||||
|
||||
TIP: If you want to keep those defaults and _add_ additional exclusions, use the configprop:spring.devtools.restart.additional-exclude[] property instead.
|
||||
@@ -700,9 +706,12 @@ For example, if you have a project with the following structure:
|
||||
|
||||
Then your `trigger-file` property would be:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
spring.devtools.restart.trigger-file=.reloadtrigger
|
||||
spring:
|
||||
devtools:
|
||||
restart:
|
||||
trigger-file: ".reloadtrigger"
|
||||
----
|
||||
|
||||
Restarts will now only happen when the `src/main/resources/.reloadtrigger` is updated.
|
||||
@@ -730,10 +739,13 @@ The `spring-devtools.properties` file can contain properties prefixed with `rest
|
||||
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:
|
||||
|
||||
[source,properties,indent=0]
|
||||
[source,yaml,indent=0,configblocks]
|
||||
----
|
||||
restart.exclude.companycommonlibs=/mycorp-common-[\\w\\d-\.]+\.jar
|
||||
restart.include.projectcommon=/mycorp-myproj-[\\w\\d-\.]+\.jar
|
||||
restart:
|
||||
exclude:
|
||||
companycommonlibs: "/mycorp-common-[\\w\\d-\\.]+\\.jar"
|
||||
include:
|
||||
projectcommon: "/mycorp-myproj-[\\w\\d-\\.]+\\.jar"
|
||||
----
|
||||
|
||||
NOTE: All property keys must be unique.
|
||||
@@ -776,12 +788,14 @@ You can configure global devtools settings by adding any of the following files
|
||||
. `spring-boot-devtools.yml`
|
||||
|
||||
Any properties added to these file apply to _all_ Spring Boot 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 the following property:
|
||||
For example, to configure restart to always use a <<using-boot-devtools-restart-triggerfile, trigger file>>, you would add the following property to your `spring-boot-devtools` file:
|
||||
|
||||
.~/.config/spring-boot/spring-boot-devtools.properties
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
spring.devtools.restart.trigger-file=.reloadtrigger
|
||||
spring:
|
||||
devtools:
|
||||
restart:
|
||||
trigger-file: ".reloadtrigger"
|
||||
----
|
||||
|
||||
NOTE: If devtools configuration files are not found in `$HOME/.config/spring-boot`, the root of the `$HOME` directory is searched for the presence of a `.spring-boot-devtools.properties` file.
|
||||
@@ -803,10 +817,13 @@ Profile specific filenames (of the form `spring-boot-devtools-<profile>.properti
|
||||
Since Spring Boot relies entirely on the IDE to compile and copy files into the location from where Spring Boot can read them, you might find that there are times when certain changes are not reflected when devtools restarts the application.
|
||||
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:
|
||||
|
||||
[source,properties,indent=0,configprops]
|
||||
[source,yaml,indent=0,configprops,configblocks]
|
||||
----
|
||||
spring.devtools.restart.poll-interval=2s
|
||||
spring.devtools.restart.quiet-period=1s
|
||||
spring:
|
||||
devtools:
|
||||
restart:
|
||||
poll-interval: "2s"
|
||||
quiet-period: "1s"
|
||||
----
|
||||
|
||||
The monitored classpath directories 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.
|
||||
|
||||
Reference in New Issue
Block a user