Use Asciidoctor extension to verify documented configuration properties
Closes gh-18451
This commit is contained in:
Andy Wilkinson
parent
a36d2cd159
commit
a6f1619971
|
|
@ -1522,8 +1522,31 @@
|
|||
<spring-framework-version>${spring-framework.version}</spring-framework-version>
|
||||
<spring-integration-version>${spring-integration.version}</spring-integration-version>
|
||||
<spring-security-version>${spring-security.version}</spring-security-version>
|
||||
<spring-webservices-version>${spring-ws.version}</spring-webservices-version> </attributes>
|
||||
<spring-webservices-version>${spring-ws.version}</spring-webservices-version>
|
||||
</attributes>
|
||||
</configuration>
|
||||
<dependencies>
|
||||
<dependency>
|
||||
<groupId>io.spring.asciidoctor</groupId>
|
||||
<artifactId>spring-asciidoctor-extensions-spring-boot</artifactId>
|
||||
<version>${spring-asciidoctor-extensions.version}</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.springframework.boot</groupId>
|
||||
<artifactId>spring-boot-actuator-autoconfigure</artifactId>
|
||||
<version>${revision}</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.springframework.boot</groupId>
|
||||
<artifactId>spring-boot-autoconfigure</artifactId>
|
||||
<version>${revision}</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.springframework.boot</groupId>
|
||||
<artifactId>spring-boot-devtools</artifactId>
|
||||
<version>${revision}</version>
|
||||
</dependency>
|
||||
</dependencies>
|
||||
<executions>
|
||||
<execution>
|
||||
<id>generate-html-documentation</id>
|
||||
|
|
@ -1551,9 +1574,9 @@
|
|||
<attribute-missing>warn</attribute-missing>
|
||||
</attributes>
|
||||
<logHandler>
|
||||
<outputToConsole>true</outputToConsole>
|
||||
<outputToConsole>false</outputToConsole>
|
||||
<failIf>
|
||||
<severity>DEBUG</severity>
|
||||
<severity>INFO</severity>
|
||||
</failIf>
|
||||
</logHandler>
|
||||
</configuration>
|
||||
|
|
@ -1581,6 +1604,12 @@
|
|||
<stylesdir>css/</stylesdir>
|
||||
<stylesheet>spring.css</stylesheet>
|
||||
</attributes>
|
||||
<logHandler>
|
||||
<outputToConsole>false</outputToConsole>
|
||||
<failIf>
|
||||
<severity>INFO</severity>
|
||||
</failIf>
|
||||
</logHandler>
|
||||
</configuration>
|
||||
</execution>
|
||||
<execution>
|
||||
|
|
|
|||
|
|
@ -81,7 +81,7 @@ They use a simple JSON format with items categorized under either "`groups`" or
|
|||
Each "`property`" is a configuration item that the user specifies with a given value.
|
||||
For example, `server.port` and `server.address` might be specified in `application.properties`, as follows:
|
||||
|
||||
[source,properties,indent=0]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
server.port=9090
|
||||
server.address=127.0.0.1
|
||||
|
|
@ -94,7 +94,7 @@ NOTE: It is not required that every "`property`" has a "`group`".
|
|||
Some properties might exist in their own right.
|
||||
|
||||
Finally, "`hints`" are additional information used to assist the user in configuring a given property.
|
||||
For example, when a developer is configuring the `spring.jpa.hibernate.ddl-auto` property, a tool can use the hints to offer some auto-completion help for the `none`, `validate`, `update`, `create`, and `create-drop` values.
|
||||
For example, when a developer is configuring the configprop:spring.jpa.hibernate.ddl-auto[] property, a tool can use the hints to offer some auto-completion help for the `none`, `validate`, `update`, `create`, and `create-drop` values.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -222,7 +222,7 @@ 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"]
|
||||
[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
|
||||
----
|
||||
spring.main.web-application-type=none
|
||||
spring.main.banner-mode=off
|
||||
|
|
@ -243,7 +243,7 @@ Consider the following application:
|
|||
|
||||
Now consider the following configuration:
|
||||
|
||||
[source,properties,indent=0,subs="verbatim,quotes,attributes"]
|
||||
[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
|
||||
----
|
||||
spring.main.sources=com.acme.Config,com.acme.ExtraConfig
|
||||
spring.main.banner-mode=console
|
||||
|
|
@ -264,8 +264,8 @@ Properties added in this way have lower priority than any added by using the def
|
|||
|
||||
You can also provide the following System properties (or environment variables) to change the behavior:
|
||||
|
||||
* `spring.config.name` (`SPRING_CONFIG_NAME`): Defaults to `application` as the root of the file name.
|
||||
* `spring.config.location` (`SPRING_CONFIG_LOCATION`): The file to load (such as a classpath resource or a URL).
|
||||
* configprop:spring.config.name[] (configprop:spring.config.name[format=envvar]): Defaults to `application` as the root of the file name.
|
||||
* configprop:spring.config.location[] (configprop:spring.config.location[format=envvar]): The file to load (such as a classpath resource or a URL).
|
||||
A separate `Environment` property source is set up for this document and it can be overridden by system properties, environment variables, or the command line.
|
||||
|
||||
No matter what you set in the environment, Spring Boot always loads `application.properties` as described above.
|
||||
|
|
@ -282,7 +282,7 @@ 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"]
|
||||
[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
|
||||
----
|
||||
server.port=${port:8080}
|
||||
----
|
||||
|
|
@ -317,10 +317,10 @@ A YAML file is parsed to a Java `Map<String,Object>` (like a JSON object), and S
|
|||
|
||||
The preceding example YAML corresponds to the following `application.properties` file:
|
||||
|
||||
[source,properties,indent=0,subs="verbatim,quotes,attributes"]
|
||||
[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
|
||||
----
|
||||
spring.application.name=cruncher
|
||||
spring.datasource.driverClassName=com.mysql.jdbc.Driver
|
||||
spring.datasource.driver-class-name=com.mysql.jdbc.Driver
|
||||
spring.datasource.url=jdbc:mysql://localhost/test
|
||||
server.port=9000
|
||||
----
|
||||
|
|
@ -331,7 +331,7 @@ See "`<<spring-boot-features.adoc#boot-features-external-config-yaml>>`" in the
|
|||
|
||||
[[howto-set-active-spring-profiles]]
|
||||
=== Set the Active Spring Profiles
|
||||
The Spring `Environment` has an API for this, but you would normally set a System property (`spring.profiles.active`) or an OS environment variable (`SPRING_PROFILES_ACTIVE`).
|
||||
The Spring `Environment` has an API for this, but you would normally set a System property (configprop:spring.profiles.active[]) or an OS environment variable (configprop:spring.profiles.active[format=envvar]).
|
||||
Also, you can launch your application with a `-D` argument (remember to put it before the main class or jar archive), as follows:
|
||||
|
||||
[indent=0,subs="verbatim,quotes,attributes"]
|
||||
|
|
@ -341,7 +341,7 @@ 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"]
|
||||
[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
|
||||
----
|
||||
spring.profiles.active=production
|
||||
----
|
||||
|
|
@ -474,7 +474,7 @@ 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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
spring.main.web-application-type=none
|
||||
----
|
||||
|
|
@ -483,8 +483,8 @@ To disable this behavior configure the `WebApplicationType` in your `application
|
|||
|
||||
[[howto-change-the-http-port]]
|
||||
=== Change the HTTP Port
|
||||
In a standalone application, the main HTTP port defaults to `8080` but can be set with `server.port` (for example, in `application.properties` or as a System property).
|
||||
Thanks to relaxed binding of `Environment` values, you can also use `SERVER_PORT` (for example, as an OS environment variable).
|
||||
In a standalone application, the main HTTP port defaults to `8080` but can be set with configprop:server.port[] (for example, in `application.properties` or as a System property).
|
||||
Thanks to relaxed binding of `Environment` values, you can also use configprop:server.port[format=envvar] (for example, as an OS environment variable).
|
||||
|
||||
To switch off the HTTP endpoints completely but still create a `WebApplicationContext`, use `server.port=-1` (doing so is sometimes useful for testing).
|
||||
|
||||
|
|
@ -536,13 +536,13 @@ 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"]
|
||||
[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
|
||||
----
|
||||
server.compression.enabled=true
|
||||
----
|
||||
|
||||
By default, responses must be at least 2048 bytes in length for compression to be performed.
|
||||
You can configure this behavior by setting the `server.compression.min-response-size` property.
|
||||
You can configure this behavior by setting the configprop:server.compression.min-response-size[] property.
|
||||
|
||||
By default, responses are compressed only if their content type is one of the following:
|
||||
|
||||
|
|
@ -555,7 +555,7 @@ By default, responses are compressed only if their content type is one of the fo
|
|||
* `application/json`
|
||||
* `application/xml`
|
||||
|
||||
You can configure this behavior by setting the `server.compression.mime-types` property.
|
||||
You can configure this behavior by setting the configprop:server.compression.mime-types[] property.
|
||||
|
||||
|
||||
|
||||
|
|
@ -564,7 +564,7 @@ You can configure this behavior by setting the `server.compression.mime-types` p
|
|||
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"]
|
||||
[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
|
||||
----
|
||||
server.port=8443
|
||||
server.ssl.key-store=classpath:keystore.jks
|
||||
|
|
@ -583,7 +583,7 @@ We recommend using `application.properties` to configure HTTPS, as the HTTP conn
|
|||
|
||||
[[howto-configure-http2]]
|
||||
=== Configure HTTP/2
|
||||
You can enable HTTP/2 support in your Spring Boot application with the `+server.http2.enabled+` configuration property.
|
||||
You can enable HTTP/2 support in your Spring Boot application with the configprop:server.http2.enabled[] configuration property.
|
||||
This support depends on the chosen web server and the application environment, since that protocol is not supported out-of-the-box by JDK8.
|
||||
|
||||
[NOTE]
|
||||
|
|
@ -754,7 +754,7 @@ 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"]
|
||||
[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
|
||||
----
|
||||
server.tomcat.basedir=my-tomcat
|
||||
server.tomcat.accesslog.enabled=true
|
||||
|
|
@ -767,18 +767,18 @@ 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"]
|
||||
[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
|
||||
----
|
||||
server.undertow.accesslog.enabled=true
|
||||
server.undertow.accesslog.pattern=%t %a "%r" %s (%D ms)
|
||||
----
|
||||
|
||||
Logs are stored in a `logs` directory relative to the working directory of the application.
|
||||
You can customize this location by setting the `server.undertow.accesslog.dir` property.
|
||||
You can customize this location by setting the configprop:server.undertow.accesslog.dir[] property.
|
||||
|
||||
Finally, access logging for Jetty can also be configured as follows:
|
||||
|
||||
[source,properties,indent=0,subs="verbatim,quotes,attributes"]
|
||||
[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
|
||||
----
|
||||
server.jetty.accesslog.enabled=true
|
||||
server.jetty.accesslog.filename=/var/log/jetty-access.log
|
||||
|
|
@ -798,7 +798,7 @@ Typically, such situations are handled through a contract with the proxy, which
|
|||
|
||||
If the proxy adds conventional `X-Forwarded-For` and `X-Forwarded-Proto` headers (most proxy servers do so), the absolute links should be rendered correctly, provided `server.forward-headers-strategy` is set to `NATIVE` or `FRAMEWORK` in your `application.properties`.
|
||||
|
||||
NOTE: If your application runs in Cloud Foundry or Heroku, the `server.forward-headers-strategy` property defaults to `NATIVE`.
|
||||
NOTE: If your application runs in Cloud Foundry or Heroku, the configprop:server.forward-headers-strategy[] property defaults to `NATIVE`.
|
||||
In all other instances, it defaults to `NONE`.
|
||||
|
||||
|
||||
|
|
@ -894,9 +894,9 @@ include::{code-examples}/context/embedded/TomcatLegacyCookieProcessorExample.jav
|
|||
=== Enable Tomcat's MBean Registry
|
||||
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 `server.tomcat.mbeanregistry.enabled` property to do so, as shown in the following example:
|
||||
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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
server.tomcat.mbeanregistry.enabled=true
|
||||
----
|
||||
|
|
@ -1054,7 +1054,7 @@ These features are described in six enums (in Jackson) that map onto properties
|
|||
| `true`, `false`
|
||||
|
||||
| `com.fasterxml.jackson.annotation.JsonInclude.Include`
|
||||
| `spring.jackson.default-property-inclusion`
|
||||
| configprop:spring.jackson.default-property-inclusion[]
|
||||
| `always`, `non_null`, `non_absent`, `non_default`, `non_empty`
|
||||
|===
|
||||
|
||||
|
|
@ -1101,7 +1101,7 @@ See the {spring-boot-autoconfigure-module-code}/web/servlet/WebMvcAutoConfigurat
|
|||
Spring Boot embraces the Servlet 3 `javax.servlet.http.Part` API to support uploading files.
|
||||
By default, Spring Boot configures Spring MVC with a maximum size of 1MB per file and a maximum of 10MB of file data in a single request.
|
||||
You may override these values, the location to which intermediate data is stored (for example, to the `/tmp` directory), and the threshold past which data is flushed to disk by using the properties exposed in the `MultipartProperties` class.
|
||||
For example, if you want to specify that files be unlimited, set the `spring.servlet.multipart.max-file-size` property to `-1`.
|
||||
For example, if you want to specify that files be unlimited, set the configprop:spring.servlet.multipart.max-file-size[] property to `-1`.
|
||||
|
||||
The multipart support is helpful when you want to receive multipart encoded file data as a `@RequestParam`-annotated parameter of type `MultipartFile` in a Spring MVC controller handler method.
|
||||
|
||||
|
|
@ -1116,7 +1116,7 @@ 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"]
|
||||
[source,properties,indent=0,subs="verbatim",configprops]
|
||||
----
|
||||
spring.mvc.servlet.path=/acme
|
||||
----
|
||||
|
|
@ -1284,7 +1284,7 @@ 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"]
|
||||
[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
|
||||
----
|
||||
logging.level.org.springframework.web=DEBUG
|
||||
logging.level.org.hibernate=ERROR
|
||||
|
|
@ -1293,7 +1293,7 @@ If the only change you need to make to logging is to set the levels of various l
|
|||
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 "logging.config" property.
|
||||
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.
|
||||
|
||||
|
||||
|
||||
|
|
@ -1369,7 +1369,7 @@ If you want to disable console logging and write output only to a file, you need
|
|||
|
||||
You also need to add `logging.file.name` to your `application.properties`, as shown in the following example:
|
||||
|
||||
[source,properties,indent=0,subs="verbatim,quotes,attributes"]
|
||||
[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
|
||||
----
|
||||
logging.file.name=myapplication.log
|
||||
----
|
||||
|
|
@ -1652,7 +1652,7 @@ If an embedded database is used and no schema manager (such as Liquibase or Flyw
|
|||
In all other cases, it defaults to `none`.
|
||||
|
||||
The dialect to use is detected by the JPA provider.
|
||||
If you prefer to set the dialect yourself, set the `spring.jpa.database-platform` property.
|
||||
If you prefer to set the dialect yourself, set the configprop:spring.jpa.database-platform[] property.
|
||||
|
||||
The most common options to set are shown in the following example:
|
||||
|
||||
|
|
@ -1922,7 +1922,7 @@ For example, you might choose to set it to the vendor name of the database (`hsq
|
|||
[NOTE]
|
||||
====
|
||||
Spring Boot automatically creates the schema of an embedded `DataSource`.
|
||||
This behavior can be customized by using the `spring.datasource.initialization-mode` property.
|
||||
This behavior can be customized by using the configprop:spring.datasource.initialization-mode[] property.
|
||||
For instance, if you want to always initialize the `DataSource` regardless of its type:
|
||||
|
||||
[indent=0,subs="verbatim,quotes,attributes"]
|
||||
|
|
@ -1971,7 +1971,7 @@ By default, they are in a folder called `classpath:db/migration`, but you can mo
|
|||
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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
spring.flyway.locations=classpath:db/migration,filesystem:/opt/migration
|
||||
----
|
||||
|
|
@ -1979,7 +1979,7 @@ For example, the following configuration would search for scripts in both the de
|
|||
You can also add a special `\{vendor}` placeholder to use vendor-specific scripts.
|
||||
Assume the following:
|
||||
|
||||
[source,properties,indent=0]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
spring.flyway.locations=classpath:db/migration/{vendor}
|
||||
----
|
||||
|
|
@ -2015,7 +2015,7 @@ 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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
spring.flyway.locations=classpath:/db/migration,classpath:/dev/db/migration
|
||||
----
|
||||
|
|
@ -2119,7 +2119,7 @@ This section answers questions that often arise from its use.
|
|||
[[howto-change-the-http-port-or-address-of-the-actuator-endpoints]]
|
||||
=== Change the HTTP Port or Address of the Actuator Endpoints
|
||||
In a standalone application, the Actuator HTTP port defaults to the same as the main HTTP port.
|
||||
To make the application listen on a different port, set the external property: `management.server.port`.
|
||||
To make the application listen on a different port, set the external property: configprop:management.server.port[].
|
||||
To listen on a completely different network address (such as when you have an internal network for management and an external one for user applications), you can also set `management.server.address` to a valid IP address to which the server is able to bind.
|
||||
|
||||
For more detail, see the {spring-boot-actuator-autoconfigure-module-code}/web/server/ManagementServerProperties.java[`ManagementServerProperties`] source code and "`<<production-ready-features.adoc#production-ready-customizing-management-server-port>>`" in the "`Production-ready features`" section.
|
||||
|
|
@ -2185,7 +2185,7 @@ 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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
server.tomcat.remote-ip-header=x-forwarded-for
|
||||
server.tomcat.protocol-header=x-forwarded-proto
|
||||
|
|
|
|||
|
|
@ -172,15 +172,15 @@ 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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.endpoint.shutdown.enabled=true
|
||||
----
|
||||
|
||||
If you prefer endpoint enablement to be opt-in rather than opt-out, set the `management.endpoints.enabled-by-default` property to `false` and use individual endpoint `enabled` properties to opt back in.
|
||||
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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.endpoints.enabled-by-default=false
|
||||
management.endpoint.info.enabled=true
|
||||
|
|
@ -299,16 +299,16 @@ To change which endpoints are exposed, use the following technology-specific `in
|
|||
|===
|
||||
| Property | Default
|
||||
|
||||
| `management.endpoints.jmx.exposure.exclude`
|
||||
| configprop:management.endpoints.jmx.exposure.exclude[]
|
||||
|
|
||||
|
||||
| `management.endpoints.jmx.exposure.include`
|
||||
| configprop:management.endpoints.jmx.exposure.include[]
|
||||
| `*`
|
||||
|
||||
| `management.endpoints.web.exposure.exclude`
|
||||
| configprop:management.endpoints.web.exposure.exclude[]
|
||||
|
|
||||
|
||||
|`management.endpoints.web.exposure.include`
|
||||
| configprop:management.endpoints.web.exposure.include[]
|
||||
| `info, health`
|
||||
|===
|
||||
|
||||
|
|
@ -319,7 +319,7 @@ 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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.endpoints.jmx.exposure.include=health,info
|
||||
----
|
||||
|
|
@ -327,7 +327,7 @@ For example, to stop exposing all endpoints over JMX and only expose the `health
|
|||
`*` 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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.endpoints.web.exposure.include=*
|
||||
management.endpoints.web.exposure.exclude=env,beans
|
||||
|
|
@ -381,10 +381,10 @@ Several other matcher methods are also available on `EndpointRequest`.
|
|||
See the API documentation ({spring-boot-actuator-restapi}/html[HTML] or {spring-boot-actuator-restapi}/pdf/spring-boot-actuator-web-api.pdf[PDF]) for details.
|
||||
|
||||
If you deploy applications behind a firewall, you may prefer that all your actuator endpoints can be accessed without requiring authentication.
|
||||
You can do so by changing the `management.endpoints.web.exposure.include` property, as follows:
|
||||
You can do so by changing the configprop:management.endpoints.web.exposure.include[] property, as follows:
|
||||
|
||||
.application.properties
|
||||
[source,properties,indent=0]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.endpoints.web.exposure.include=*
|
||||
----
|
||||
|
|
@ -414,7 +414,7 @@ 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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.endpoint.beans.cache.time-to-live=10s
|
||||
----
|
||||
|
|
@ -441,10 +441,10 @@ When the management context path is set to `/`, the discovery page is disabled t
|
|||
https://en.wikipedia.org/wiki/Cross-origin_resource_sharing[Cross-origin resource sharing] (CORS) is a https://www.w3.org/TR/cors/[W3C specification] that lets you specify in a flexible way what kind of cross-domain requests are authorized.
|
||||
If you use Spring MVC or Spring WebFlux, Actuator's web endpoints can be configured to support such scenarios.
|
||||
|
||||
CORS support is disabled by default and is only enabled once the `management.endpoints.web.cors.allowed-origins` property has been set.
|
||||
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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.endpoints.web.cors.allowed-origins=https://example.com
|
||||
management.endpoints.web.cors.allowed-methods=GET,POST
|
||||
|
|
@ -623,7 +623,7 @@ The `@Endpoint` and `@WebEndpoint` annotations should be preferred whenever poss
|
|||
=== Health Information
|
||||
You can use health information to check the status of your running application.
|
||||
It is often used by monitoring software to alert someone when a production system goes down.
|
||||
The information exposed by the `health` endpoint depends on the `management.endpoint.health.show-details` and `management.endpoint.health.show-components` properties which can be configured with one of the following values:
|
||||
The information exposed by the `health` endpoint depends on the configprop:management.endpoint.health.show-details[] and configprop:management.endpoint.health.show-components[] properties which can be configured with one of the following values:
|
||||
|
||||
[cols="1, 3"]
|
||||
|===
|
||||
|
|
@ -643,7 +643,7 @@ The information exposed by the `health` endpoint depends on the `management.endp
|
|||
The default value is `never`.
|
||||
A user is considered to be authorized when they are in one or more of the endpoint's roles.
|
||||
If the endpoint has no configured roles (the default) all authenticated users are considered to be authorized.
|
||||
The roles can be configured using the `management.endpoint.health.roles` property.
|
||||
The roles can be configured using the configprop:management.endpoint.health.roles[] property.
|
||||
|
||||
NOTE: If you have secured your application and wish to use `always`, your security configuration must permit access to the health endpoint for both authenticated and unauthenticated users.
|
||||
|
||||
|
|
@ -713,7 +713,7 @@ The following `HealthIndicators` are auto-configured by Spring Boot when appropr
|
|||
| Checks that a Solr server is up.
|
||||
|===
|
||||
|
||||
TIP: You can disable them all by setting the `management.health.defaults.enabled` property.
|
||||
TIP: You can disable them all by setting the configprop:management.health.defaults.enabled[] property.
|
||||
|
||||
|
||||
|
||||
|
|
@ -748,12 +748,12 @@ NOTE: The identifier for a given `HealthIndicator` is the name of the bean witho
|
|||
In the preceding example, the health information is available in an entry named `my`.
|
||||
|
||||
In addition to Spring Boot's predefined {spring-boot-actuator-module-code}/health/Status.java[`Status`] types, it is also possible for `Health` to return a custom `Status` that represents a new system state.
|
||||
In such cases, a custom implementation of the {spring-boot-actuator-module-code}/health/StatusAggregator.java[`StatusAggregator`] interface also needs to be provided, or the default implementation has to be configured by using the `management.endpoint.health.status.order` configuration property.
|
||||
In such cases, a custom implementation of the {spring-boot-actuator-module-code}/health/StatusAggregator.java[`StatusAggregator`] interface also needs to be provided, or the default implementation has to be configured by using the configprop:management.endpoint.health.status.order[] configuration property.
|
||||
|
||||
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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.endpoint.health.status.order=fatal,down,out-of-service,unknown,up
|
||||
----
|
||||
|
|
@ -762,7 +762,7 @@ The HTTP status code in the response reflects the overall health status (for exa
|
|||
You might also want to register custom status mappings if you access the health endpoint over HTTP.
|
||||
For example, the following property maps `FATAL` to 503 (service unavailable):
|
||||
|
||||
[source,properties,indent=0]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.endpoint.health.status.http-mapping.fatal=503
|
||||
----
|
||||
|
|
@ -851,7 +851,7 @@ For example, if you deploy your application to Kubernetes, you may want one diff
|
|||
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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.endpoint.health.group.custom.include=db
|
||||
----
|
||||
|
|
@ -861,7 +861,7 @@ You can then check the result by hitting `http://localhost:8080/actuator/health/
|
|||
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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.endpoint.health.group.custom.show-details=when-authorized
|
||||
management.endpoint.health.group.custom.roles=admin
|
||||
|
|
@ -899,7 +899,7 @@ The following `InfoContributor` beans are auto-configured by Spring Boot, when a
|
|||
| Exposes build information if a `META-INF/build-info.properties` file is available.
|
||||
|===
|
||||
|
||||
TIP: It is possible to disable them all by setting the `management.info.defaults.enabled` property.
|
||||
TIP: It is possible to disable them all by setting the configprop:management.info.defaults.enabled[] property.
|
||||
|
||||
|
||||
|
||||
|
|
@ -909,7 +909,7 @@ 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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
info.app.encoding=UTF-8
|
||||
info.app.java.source=1.8
|
||||
|
|
@ -922,7 +922,7 @@ 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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
info.app.encoding=@project.build.sourceEncoding@
|
||||
info.app.java.source=@java.version@
|
||||
|
|
@ -940,9 +940,9 @@ If a `GitProperties` bean is available, the `git.branch`, `git.commit.id`, and `
|
|||
TIP: A `GitProperties` bean is auto-configured if a `git.properties` file is available at the root of the classpath.
|
||||
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 `management.info.git.mode` property, as follows:
|
||||
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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.info.git.mode=full
|
||||
----
|
||||
|
|
@ -1012,9 +1012,9 @@ TIP: Actuator is supported natively with Spring MVC, Spring WebFlux, and Jersey.
|
|||
=== Customizing the Management Endpoint Paths
|
||||
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 `management.endpoints.web.base-path` property to change the prefix for your management endpoint, as shown in the following example:
|
||||
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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.endpoints.web.base-path=/manage
|
||||
----
|
||||
|
|
@ -1024,12 +1024,12 @@ The preceding `application.properties` example changes the endpoint from `/actua
|
|||
NOTE: Unless the management port has been configured to <<production-ready-customizing-management-server-port,expose endpoints by using a different HTTP port>>, `management.endpoints.web.base-path` is relative to `server.servlet.context-path`.
|
||||
If `management.server.port` is configured, `management.endpoints.web.base-path` is relative to `management.server.servlet.context-path`.
|
||||
|
||||
If you want to map endpoints to a different path, you can use the `management.endpoints.web.path-mapping` property.
|
||||
If you want to map endpoints to a different path, you can use the configprop:management.endpoints.web.path-mapping[] property.
|
||||
|
||||
The following example remaps `/actuator/health` to `/healthcheck`:
|
||||
|
||||
.application.properties
|
||||
[source,properties,indent=0]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.endpoints.web.base-path=/
|
||||
management.endpoints.web.path-mapping.health=healthcheck
|
||||
|
|
@ -1042,9 +1042,9 @@ The following example remaps `/actuator/health` to `/healthcheck`:
|
|||
Exposing management endpoints by using the default HTTP port is a sensible choice for cloud-based deployments.
|
||||
If, however, your application runs inside your own data center, you may prefer to expose endpoints by using a different HTTP port.
|
||||
|
||||
You can set the `management.server.port` property to change the HTTP port, as shown in the following example:
|
||||
You can set the configprop:management.server.port[] property to change the HTTP port, as shown in the following example:
|
||||
|
||||
[source,properties,indent=0]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.server.port=8081
|
||||
----
|
||||
|
|
@ -1059,7 +1059,7 @@ 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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
server.port=8443
|
||||
server.ssl.enabled=true
|
||||
|
|
@ -1071,7 +1071,7 @@ For example, doing so lets a management server be available over HTTP while the
|
|||
|
||||
Alternatively, both the main server and the management server can use SSL but with different key stores, as follows:
|
||||
|
||||
[source,properties,indent=0]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
server.port=8443
|
||||
server.ssl.enabled=true
|
||||
|
|
@ -1087,14 +1087,14 @@ Alternatively, both the main server and the management server can use SSL but wi
|
|||
|
||||
[[production-ready-customizing-management-server-address]]
|
||||
=== Customizing the Management Server Address
|
||||
You can customize the address that the management endpoints are available on by setting the `management.server.address` property.
|
||||
You can customize the address that the management endpoints are available on by setting the configprop:management.server.address[] property.
|
||||
Doing so can be useful if you want to listen only on an internal or ops-facing network or to listen only for connections from `localhost`.
|
||||
|
||||
NOTE: You can listen on a different address only when the port differs from the main server port.
|
||||
|
||||
The following example `application.properties` does not allow remote management connections:
|
||||
|
||||
[source,properties,indent=0]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.server.port=8081
|
||||
management.server.address=127.0.0.1
|
||||
|
|
@ -1106,14 +1106,14 @@ 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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.server.port=-1
|
||||
----
|
||||
|
||||
This can be achieved using the `management.endpoints.web.exposure.exclude` property as well, as shown in following example:
|
||||
This can be achieved using the configprop:management.endpoints.web.exposure.exclude[] property as well, as shown in following example:
|
||||
|
||||
[source,properties,indent=0]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.endpoints.web.exposure.exclude=*
|
||||
----
|
||||
|
|
@ -1123,7 +1123,7 @@ This can be achieved using the `management.endpoints.web.exposure.exclude` prope
|
|||
[[production-ready-jmx]]
|
||||
== Monitoring and Management over JMX
|
||||
Java Management Extensions (JMX) provide a standard mechanism to monitor and manage applications.
|
||||
By default, this feature is not enabled and can be turned on with the configuration property `spring.jmx.enabled=true`.
|
||||
By default, this feature is not enabled and can be turned on by setting the configuration property configprop:spring.jmx.enabled[] to `true`.
|
||||
Spring Boot exposes management endpoints as JMX MBeans under the `org.springframework.boot` domain by default.
|
||||
|
||||
|
||||
|
|
@ -1134,12 +1134,12 @@ The name of the MBean is usually generated from the `id` of the endpoint.
|
|||
For example, the `health` endpoint is exposed as `org.springframework.boot:type=Endpoint,name=Health`.
|
||||
|
||||
If your application contains more than one Spring `ApplicationContext`, you may find that names clash.
|
||||
To solve this problem, you can set the `spring.jmx.unique-names` property to `true` so that MBean names are always unique.
|
||||
To solve this problem, you can set the configprop:spring.jmx.unique-names[] property to `true` so that MBean names are always unique.
|
||||
|
||||
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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
spring.jmx.unique-names=true
|
||||
management.endpoints.jmx.domain=com.example.myapp
|
||||
|
|
@ -1149,9 +1149,9 @@ The following settings show an example of doing so in `application.properties`:
|
|||
|
||||
[[production-ready-disable-jmx-endpoints]]
|
||||
=== Disabling JMX Endpoints
|
||||
If you do not want to expose endpoints over JMX, you can set the `management.endpoints.jmx.exposure.exclude` property to `*`, as shown in the following example:
|
||||
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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.endpoints.jmx.exposure.exclude=*
|
||||
----
|
||||
|
|
@ -1172,7 +1172,7 @@ For example, with Maven, you would add the following dependency:
|
|||
</dependency>
|
||||
----
|
||||
|
||||
The Jolokia endpoint can then be exposed by adding `jolokia` or `*` to the `management.endpoints.web.exposure.include` property.
|
||||
The Jolokia endpoint can then be exposed by adding `jolokia` or `*` to the configprop:management.endpoints.web.exposure.include[] property.
|
||||
You can then access it by using `/actuator/jolokia` on your management HTTP server.
|
||||
|
||||
|
||||
|
|
@ -1183,7 +1183,7 @@ 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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.endpoint.jolokia.config.debug=true
|
||||
----
|
||||
|
|
@ -1192,9 +1192,9 @@ To do so, prefix the parameter with `management.endpoint.jolokia.config.`, as sh
|
|||
|
||||
[[production-ready-disabling-jolokia]]
|
||||
==== Disabling Jolokia
|
||||
If you use Jolokia but do not want Spring Boot to configure it, set the `management.endpoint.jolokia.enabled` property to `false`, as follows:
|
||||
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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.endpoint.jolokia.enabled=false
|
||||
----
|
||||
|
|
@ -1270,14 +1270,14 @@ 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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.metrics.export.datadog.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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.metrics.use-global-registry=false
|
||||
----
|
||||
|
|
@ -1323,7 +1323,7 @@ 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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.metrics.export.appoptics.api-token=YOUR_TOKEN
|
||||
----
|
||||
|
|
@ -1335,7 +1335,7 @@ 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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.metrics.export.atlas.uri=https://atlas.example.com:7101/api/v1/publish
|
||||
----
|
||||
|
|
@ -1347,14 +1347,14 @@ 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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.metrics.export.datadog.step=30s
|
||||
----
|
||||
|
|
@ -1366,7 +1366,7 @@ 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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.metrics.export.dynatrace.api-token=YOUR_TOKEN
|
||||
management.metrics.export.dynatrace.device-id=YOUR_DEVICE_ID
|
||||
|
|
@ -1375,7 +1375,7 @@ To export metrics to {micrometer-registry-docs}/dynatrace[Dynatrace], your API t
|
|||
|
||||
You can also change the interval at which metrics are sent to Dynatrace:
|
||||
|
||||
[source,properties,indent=0]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.metrics.export.dynatrace.step=30s
|
||||
----
|
||||
|
|
@ -1387,7 +1387,7 @@ 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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.metrics.export.elastic.host=https://elastic.example.com:8086
|
||||
----
|
||||
|
|
@ -1399,7 +1399,7 @@ 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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.metrics.export.ganglia.host=ganglia.example.com
|
||||
management.metrics.export.ganglia.port=9649
|
||||
|
|
@ -1412,7 +1412,7 @@ 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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.metrics.export.graphite.host=graphite.example.com
|
||||
management.metrics.export.graphite.port=9004
|
||||
|
|
@ -1438,14 +1438,14 @@ 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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.metrics.export.humio.tags.alpha=a
|
||||
management.metrics.export.humio.tags.bravo=b
|
||||
|
|
@ -1458,7 +1458,7 @@ 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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.metrics.export.influx.uri=https://influx.example.com:8086
|
||||
----
|
||||
|
|
@ -1471,7 +1471,7 @@ 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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.metrics.export.jmx.domain=com.example.app.metrics
|
||||
----
|
||||
|
|
@ -1496,7 +1496,7 @@ 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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.metrics.export.kairos.uri=https://kairosdb.example.com:8080/api/v1/datapoints
|
||||
----
|
||||
|
|
@ -1508,7 +1508,7 @@ 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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.metrics.export.newrelic.api-key=YOUR_KEY
|
||||
management.metrics.export.newrelic.account-id=YOUR_ACCOUNT_ID
|
||||
|
|
@ -1516,7 +1516,7 @@ To export metrics to https://newrelic.com[New Relic], your API key and account i
|
|||
|
||||
You can also change the interval at which metrics are sent to New Relic:
|
||||
|
||||
[source,properties,indent=0]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.metrics.export.newrelic.step=30s
|
||||
----
|
||||
|
|
@ -1564,14 +1564,14 @@ 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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.metrics.export.signalfx.step=30s
|
||||
----
|
||||
|
|
@ -1586,7 +1586,7 @@ 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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.metrics.export.simple.enabled=false
|
||||
----
|
||||
|
|
@ -1599,7 +1599,7 @@ 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 and port to use can be provided using:
|
||||
|
||||
[source,properties,indent=0]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.metrics.export.statsd.host=statsd.example.com
|
||||
management.metrics.export.statsd.port=9125
|
||||
|
|
@ -1607,7 +1607,7 @@ The StatsD agent host and port to use can be provided using:
|
|||
|
||||
You can also change the StatsD line protocol to use (default to Datadog):
|
||||
|
||||
[source,properties,indent=0]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.metrics.export.statsd.flavor=etsy
|
||||
----
|
||||
|
|
@ -1619,14 +1619,14 @@ 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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.metrics.export.wavefront.uri=proxy://localhost:2878
|
||||
----
|
||||
|
|
@ -1635,7 +1635,7 @@ TIP: If publishing metrics to a Wavefront proxy (as described in https://docs.wa
|
|||
|
||||
You can also change the interval at which metrics are sent to Wavefront:
|
||||
|
||||
[source,properties,indent=0]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.metrics.export.wavefront.step=30s
|
||||
----
|
||||
|
|
@ -1688,7 +1688,7 @@ Alternatively, when set to `false`, you can enable instrumentation by adding `@T
|
|||
Long task timers require a separate metric name, and can be stacked with a short task timer.
|
||||
|
||||
By default, metrics are generated with the name, `http.server.requests`.
|
||||
The name can be customized by setting the `management.metrics.web.server.requests-metric-name` property.
|
||||
The name can be customized by setting the configprop:management.metrics.web.server.request.metric-name[] property.
|
||||
|
||||
By default, Spring MVC-related metrics are tagged with the following information:
|
||||
|
||||
|
|
@ -1721,7 +1721,7 @@ To customize the tags, provide a `@Bean` that implements `WebMvcTagsProvider`.
|
|||
Auto-configuration enables the instrumentation of all requests handled by WebFlux controllers and functional handlers.
|
||||
|
||||
By default, metrics are generated with the name `http.server.requests`.
|
||||
You can customize the name by setting the `management.metrics.web.server.requests-metric-name` property.
|
||||
You can customize the name by setting the configprop:management.metrics.web.server.request.metric-name[] property.
|
||||
|
||||
By default, WebFlux-related metrics are tagged with the following information:
|
||||
|
||||
|
|
@ -1774,7 +1774,7 @@ Alternatively, when set to `false`, you can enable instrumentation by adding `@T
|
|||
Long task timers require a separate metric name, and can be stacked with a short task timer.
|
||||
|
||||
By default, metrics are generated with the name, `http.server.requests`.
|
||||
The name can be customized by setting the `management.metrics.web.server.requests-metric-name` property.
|
||||
The name can be customized by setting the configprop:management.metrics.web.server.request.metric-name[] property.
|
||||
|
||||
By default, Jersey server metrics are tagged with the following information:
|
||||
|
||||
|
|
@ -1813,7 +1813,7 @@ For that, you have to get injected with an auto-configured builder and use it to
|
|||
It is also possible to apply manually the customizers responsible for this instrumentation, namely `MetricsRestTemplateCustomizer` and `MetricsWebClientCustomizer`.
|
||||
|
||||
By default, metrics are generated with the name, `http.client.requests`.
|
||||
The name can be customized by setting the `management.metrics.web.client.requests-metric-name` property.
|
||||
The name can be customized by setting the configprop:management.metrics.web.client.request.metric-name[] property.
|
||||
|
||||
By default, metrics generated by an instrumented client are tagged with the following information:
|
||||
|
||||
|
|
@ -1887,7 +1887,7 @@ 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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
spring.jpa.properties.hibernate.generate_statistics=true
|
||||
----
|
||||
|
|
@ -1933,7 +1933,7 @@ 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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.metrics.tags.region=us-east-1
|
||||
management.metrics.tags.stack=prod
|
||||
|
|
@ -1951,7 +1951,7 @@ 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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.metrics.enable.example.remote=false
|
||||
----
|
||||
|
|
@ -1962,19 +1962,19 @@ The following properties allow per-meter customization:
|
|||
|===
|
||||
| Property | Description
|
||||
|
||||
| `management.metrics.enable`
|
||||
| configprop:management.metrics.enable[]
|
||||
| Whether to deny meters from emitting any metrics.
|
||||
|
||||
| `management.metrics.distribution.percentiles-histogram`
|
||||
| configprop:management.metrics.distribution.percentiles-histogram[]
|
||||
| Whether to publish a histogram suitable for computing aggregable (across dimension) percentile approximations.
|
||||
|
||||
| `management.metrics.distribution.minimum-expected-value`, `management.metrics.distribution.maximum-expected-value`
|
||||
| configprop:management.metrics.distribution.minimum-expected-value[], configprop:management.metrics.distribution.maximum-expected-value[]
|
||||
| Publish less histogram buckets by clamping the range of expected values.
|
||||
|
||||
| `management.metrics.distribution.percentiles`
|
||||
| configprop:management.metrics.distribution.percentiles[]
|
||||
| Publish percentile values computed in your application
|
||||
|
||||
| `management.metrics.distribution.sla`
|
||||
| configprop:management.metrics.distribution.sla[]
|
||||
| Publish a cumulative histogram with buckets defined by your SLAs.
|
||||
|===
|
||||
|
||||
|
|
@ -2042,7 +2042,7 @@ The `httptrace` endpoint can be used to obtain information about the request-res
|
|||
|
||||
[[production-ready-http-tracing-custom]]
|
||||
=== Custom HTTP tracing
|
||||
To customize the items that are included in each trace, use the `management.trace.http.include` configuration property.
|
||||
To customize the items that are included in each trace, use the configprop:management.trace.http.include[] configuration property.
|
||||
For advanced customization, consider registering your own `HttpExchangeTracer` implementation.
|
||||
|
||||
|
||||
|
|
@ -2100,7 +2100,7 @@ If you want to fully disable the `/cloudfoundryapplication` endpoints, you can a
|
|||
|
||||
|
||||
.application.properties
|
||||
[source,properties,indent=0]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.cloudfoundry.enabled=false
|
||||
----
|
||||
|
|
@ -2113,7 +2113,7 @@ 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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
management.cloudfoundry.skip-ssl-validation=true
|
||||
----
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load Diff
|
|
@ -410,7 +410,7 @@ If you find that specific auto-configuration classes that you do not want are be
|
|||
----
|
||||
|
||||
If the class is not on the classpath, you can use the `excludeName` attribute of the annotation and specify the fully qualified name instead.
|
||||
Finally, you can also control the list of auto-configuration classes to exclude by using the `spring.autoconfigure.exclude` property.
|
||||
Finally, you can also control the list of auto-configuration classes to exclude by using the configprop:spring.autoconfigure.exclude[] property.
|
||||
|
||||
TIP: You can define exclusions both at the annotation level and by using the property.
|
||||
|
||||
|
|
@ -685,14 +685,14 @@ While caching is very beneficial in production, it can be counter-productive dur
|
|||
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.
|
||||
For example, Thymeleaf offers the configprop:spring.thymeleaf.cache[] property.
|
||||
Rather than needing to set these properties manually, the `spring-boot-devtools` module automatically applies sensible development-time configuration.
|
||||
|
||||
Because you need more information about web requests while developing Spring MVC and Spring WebFlux applications, developer tools will enable `DEBUG` logging for the `web` logging group.
|
||||
This will give you information about the incoming request, which handler is processing it, the response outcome, etc.
|
||||
If you wish to log all request details (including potentially sensitive information), you can turn on the `spring.http.log-request-details` configuration property.
|
||||
If you wish to log all request details (including potentially sensitive information), you can turn on the configprop:spring.http.log-request-details[] configuration property.
|
||||
|
||||
NOTE: If you don't want property defaults to be applied you can set `spring.devtools.add-properties` to `false` in your `application.properties`.
|
||||
NOTE: If you don't want property defaults to be applied you can set configprop:spring.devtools.add-properties[] to `false` in your `application.properties`.
|
||||
|
||||
TIP: For a complete list of the properties that are applied by the devtools, see {spring-boot-devtools-module-code}/env/DevToolsPropertyDefaultsPostProcessor.java[DevToolsPropertyDefaultsPostProcessor].
|
||||
|
||||
|
|
@ -763,7 +763,7 @@ 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 <<using-boot-devtools-livereload, live reload>>.
|
||||
If you want to customize these exclusions, you can use the `spring.devtools.restart.exclude` property.
|
||||
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]
|
||||
|
|
@ -771,24 +771,24 @@ For example, to exclude only `/static` and `/public` you would set the following
|
|||
spring.devtools.restart.exclude=static/**,public/**
|
||||
----
|
||||
|
||||
TIP: If you want to keep those defaults and _add_ additional exclusions, use the `spring.devtools.restart.additional-exclude` property instead.
|
||||
TIP: If you want to keep those defaults and _add_ additional exclusions, use the configprop:spring.devtools.restart.additional-exclude[] property instead.
|
||||
|
||||
|
||||
|
||||
[[using-boot-devtools-restart-additional-paths]]
|
||||
==== Watching Additional Paths
|
||||
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 <<using-boot-devtools-restart-exclude, described earlier>> to control whether changes beneath the additional paths trigger a full restart or a <<using-boot-devtools-livereload, live reload>>.
|
||||
To do so, use the configprop:spring.devtools.restart.additional-paths[] property to configure additional paths to watch for changes.
|
||||
You can use the configprop:spring.devtools.restart.exclude[] property <<using-boot-devtools-restart-exclude, described earlier>> to control whether changes beneath the additional paths trigger a full restart or a <<using-boot-devtools-livereload, live reload>>.
|
||||
|
||||
|
||||
|
||||
[[using-boot-devtools-restart-disable]]
|
||||
==== Disabling Restart
|
||||
If you do not want to use the restart feature, you can disable it by using the `spring.devtools.restart.enabled` property.
|
||||
If you do not want to use the restart feature, you can disable it by using the configprop: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:
|
||||
If you need to _completely_ disable restart support (for example, because it does not work with a specific library), you need to set the configprop:spring.devtools.restart.enabled[] `System` property to `false` before calling `SpringApplication.run(...)`, as shown in the following example:
|
||||
|
||||
[source,java,indent=0]
|
||||
----
|
||||
|
|
@ -807,7 +807,7 @@ To do so, you can use a "`trigger file`", which is a special file that must be m
|
|||
|
||||
NOTE: Any update to the file will trigger a check, but restart only actually occurs if Devtools has detected it has something to do.
|
||||
|
||||
To use a trigger file, set the `spring.devtools.restart.trigger-file` property to the name (excluding any path) of your trigger file.
|
||||
To use a trigger file, set the configprop:spring.devtools.restart.trigger-file[] property to the name (excluding any path) of your trigger file.
|
||||
The trigger file must appear somewhere on your classpath.
|
||||
|
||||
For example, if you have a project with the following structure:
|
||||
|
|
@ -822,7 +822,7 @@ For example, if you have a project with the following structure:
|
|||
|
||||
Then your `trigger-file` property would be:
|
||||
|
||||
[source,properties,indent=0]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
spring.devtools.restart.trigger-file=.reloadtrigger
|
||||
----
|
||||
|
|
@ -881,7 +881,7 @@ 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 http://livereload.com/extensions/[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`.
|
||||
If you do not want to start the LiveReload server when your application runs, you can set the configprop:spring.devtools.livereload.enabled[] property to `false`.
|
||||
|
||||
NOTE: You can only run one LiveReload server at a time.
|
||||
Before starting your application, ensure that no other LiveReload servers are running.
|
||||
|
|
@ -901,9 +901,9 @@ Any properties added to these file apply to _all_ Spring Boot applications on yo
|
|||
For example, to configure restart to always use a <<using-boot-devtools-restart-triggerfile, trigger file>>, you would add the following property:
|
||||
|
||||
.~/config/spring-boot/spring-boot-devtools.properties
|
||||
[source,properties,indent=0]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
spring.devtools.reload.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` folder is searched for the presence of a `.spring-boot-devtools.properties` file.
|
||||
|
|
@ -935,9 +935,9 @@ To enable it, you need to make sure that `devtools` is included in the repackage
|
|||
</build>
|
||||
----
|
||||
|
||||
Then you need to set a `spring.devtools.remote.secret` property, as shown in the following example:
|
||||
Then you need to set a configprop:spring.devtools.remote.secret[] property, as shown in the following example:
|
||||
|
||||
[source,properties,indent=0]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
spring.devtools.remote.secret=mysecret
|
||||
----
|
||||
|
|
@ -946,7 +946,7 @@ WARNING: Enabling `spring-boot-devtools` on a remote application is a security r
|
|||
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 server component is automatically enabled when the configprop:spring.devtools.remote.secret[] property is set.
|
||||
The client component must be launched manually.
|
||||
|
||||
|
||||
|
|
@ -984,7 +984,7 @@ A running remote client might resemble the following listing:
|
|||
----
|
||||
|
||||
NOTE: 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.
|
||||
This is how the configprop:spring.devtools.remote.secret[] property is read and passed to the server for authentication.
|
||||
|
||||
TIP: It is always advisable to use `https://` as the connection protocol, so that traffic is encrypted and passwords cannot be intercepted.
|
||||
|
||||
|
|
@ -1017,7 +1017,7 @@ But it may also lead to application code inconsistency and failure to restart af
|
|||
|
||||
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]
|
||||
[source,properties,indent=0,configprops]
|
||||
----
|
||||
spring.devtools.restart.poll-interval=2s
|
||||
spring.devtools.restart.quiet-period=1s
|
||||
|
|
|
|||
|
|
@ -26,10 +26,11 @@
|
|||
<maven.version>3.5.4</maven.version>
|
||||
<maven-resolver.version>1.1.1</maven-resolver.version>
|
||||
<spock.version>1.0-groovy-2.4</spock.version>
|
||||
<testcontainers.version>1.12.2</testcontainers.version>
|
||||
<testng.version>6.14.3</testng.version>
|
||||
<spring-asciidoctor-extensions.version>0.3.0.BUILD-SNAPSHOT</spring-asciidoctor-extensions.version>
|
||||
<spring-doc-resources.version>0.1.3.RELEASE</spring-doc-resources.version>
|
||||
<spring-doc-resources.url>https://repo.spring.io/release/io/spring/docresources/spring-doc-resources/${spring-doc-resources.version}/spring-doc-resources-${spring-doc-resources.version}.zip</spring-doc-resources.url>
|
||||
<testcontainers.version>1.12.2</testcontainers.version>
|
||||
<testng.version>6.14.3</testng.version>
|
||||
</properties>
|
||||
<scm>
|
||||
<url>https://github.com/spring-projects/spring-boot</url>
|
||||
|
|
|
|||
|
|
@ -360,7 +360,7 @@
|
|||
<dependency>
|
||||
<groupId>io.spring.asciidoctor</groupId>
|
||||
<artifactId>spring-asciidoctor-extensions</artifactId>
|
||||
<version>0.2.0.RELEASE</version>
|
||||
<version>${spring-asciidoctor-extensions.version}</version>
|
||||
</dependency>
|
||||
</dependencies>
|
||||
</plugin>
|
||||
|
|
|
|||
Loading…
Reference in New Issue