Polish asciidoc formatting

pull/26632/head
Phillip Webb 4 years ago
parent a28072bab4
commit 2dbf39c738

@ -1,13 +1,11 @@
[[audit-events]]
= Audit Events (`auditevents`)
The `auditevents` endpoint provides information about the application's audit events.
[[audit-events-retrieving]]
== Retrieving Audit Events
To retrieve the audit events, make a `GET` request to `/actuator/auditevents`, as shown in the following curl-based example:
include::{snippets}/auditevents/filtered/curl-request.adoc[]
@ -21,7 +19,6 @@ include::{snippets}/auditevents/filtered/http-response.adoc[]
[[audit-events-retrieving-query-parameters]]
=== Query Parameters
The endpoint uses query parameters to limit the events that it returns.
The following table shows the supported query parameters:
@ -32,7 +29,6 @@ include::{snippets}/auditevents/filtered/request-parameters.adoc[]
[[audit-events-retrieving-response-structure]]
=== Response Structure
The response contains details of all of the audit events that matched the query.
The following table describes the structure of the response:

@ -1,13 +1,11 @@
[[beans]]
= Beans (`beans`)
The `beans` endpoint provides information about the application's beans.
[[beans-retrieving]]
== Retrieving the Beans
To retrieve the beans, make a `GET` request to `/actuator/beans`, as shown in the following curl-based example:
include::{snippets}/beans/curl-request.adoc[]
@ -20,7 +18,6 @@ include::{snippets}/beans/http-response.adoc[]
[[beans-retrieving-response-structure]]
=== Response Structure
The response contains details of the application's beans.
The following table describes the structure of the response:

@ -1,6 +1,5 @@
[[caches]]
= Caches (`caches`)
The `caches` endpoint provides access to the application's caches.

@ -1,13 +1,11 @@
[[conditions]]
= Conditions Evaluation Report (`conditions`)
The `conditions` endpoint provides information about the evaluation of conditions on configuration and auto-configuration classes.
[[conditions-retrieving]]
== Retrieving the Report
To retrieve the report, make a `GET` request to `/actuator/conditions`, as shown in the following curl-based example:
include::{snippets}/conditions/curl-request.adoc[]
@ -20,7 +18,6 @@ include::{snippets}/conditions/http-response.adoc[]
[[conditions-retrieving-response-structure]]
=== Response Structure
The response contains details of the application's condition evaluation.
The following table describes the structure of the response:

@ -1,13 +1,11 @@
[[configprops]]
= Configuration Properties (`configprops`)
The `configprops` endpoint provides information about the application's `@ConfigurationProperties` beans.
[[configprops-retrieving]]
== Retrieving All @ConfigurationProperties Beans
To retrieve all of the `@ConfigurationProperties` beans, make a `GET` request to `/actuator/configprops`, as shown in the following curl-based example:
include::{snippets}/configprops/all/curl-request.adoc[]
@ -20,7 +18,6 @@ include::{snippets}/configprops/all/http-response.adoc[]
[[configprops-retrieving-response-structure]]
=== Response Structure
The response contains details of the application's `@ConfigurationProperties` beans.
The following table describes the structure of the response:
@ -31,7 +28,6 @@ include::{snippets}/configprops/all/response-fields.adoc[]
[[configprops-retrieving-by-prefix]]
== Retrieving @ConfigurationProperties Beans By Prefix
To retrieve the `@ConfigurationProperties` beans mapped under a certain prefix, make a `GET` request to `/actuator/configprops/\{prefix}`, as shown in the following curl-based example:
include::{snippets}/configprops/prefixed/curl-request.adoc[]
@ -46,7 +42,6 @@ NOTE: The `\{prefix}` does not need to be exact, a more general prefix will retu
[[configprops-retrieving-by-prefix-response-structure]]
=== Response Structure
The response contains details of the application's `@ConfigurationProperties` beans.
The following table describes the structure of the response:

@ -1,13 +1,11 @@
[[env]]
= Environment (`env`)
The `env` endpoint provides information about the application's `Environment`.
[[env-entire]]
== Retrieving the Entire Environment
To retrieve the entire environment, make a `GET` request to `/actuator/env`, as shown in the following curl-based example:
include::{snippets}/env/all/curl-request.adoc[]
@ -20,7 +18,6 @@ include::{snippets}/env/all/http-response.adoc[]
[[env-entire-response-structure]]
=== Response Structure
The response contains details of the application's `Environment`.
The following table describes the structure of the response:
@ -31,7 +28,6 @@ include::{snippets}/env/all/response-fields.adoc[]
[[env-single-property]]
== Retrieving a Single Property
To retrieve a single property, make a `GET` request to `/actuator/env/{property.name}`, as shown in the following curl-based example:
include::{snippets}/env/single/curl-request.adoc[]
@ -45,7 +41,6 @@ include::{snippets}/env/single/http-response.adoc[]
[[env-single-response-structure]]
=== Response Structure
The response contains details of the requested property.
The following table describes the structure of the response:

@ -1,13 +1,11 @@
[[flyway]]
= Flyway (`flyway`)
The `flyway` endpoint provides information about database migrations performed by Flyway.
[[flyway-retrieving]]
== Retrieving the Migrations
To retrieve the migrations, make a `GET` request to `/actuator/flyway`, as shown in the following curl-based example:
include::{snippets}/flyway/curl-request.adoc[]
@ -20,7 +18,6 @@ include::{snippets}/flyway/http-response.adoc[]
[[flyway-retrieving-response-structure]]
=== Response Structure
The response contains details of the application's Flyway migrations.
The following table describes the structure of the response:

@ -1,13 +1,11 @@
[[heapdump]]
= Heap Dump (`heapdump`)
The `heapdump` endpoint provides a heap dump from the application's JVM.
[[heapdump-retrieving]]
== Retrieving the Heap Dump
To retrieve the heap dump, make a `GET` request to `/actuator/heapdump`.
The response is binary data in https://docs.oracle.com/javase/8/docs/technotes/samples/hprof.html[HPROF] format and can be large.
Typically, you should save the response to disk for subsequent analysis.

@ -1,13 +1,11 @@
[[http-trace]]
= HTTP Trace (`httptrace`)
The `httptrace` endpoint provides information about HTTP request-response exchanges.
[[http-trace-retrieving]]
== Retrieving the Traces
To retrieve the traces, make a `GET` request to `/actuator/httptrace`, as shown in the following curl-based example:
include::{snippets}/httptrace/curl-request.adoc[]
@ -20,7 +18,6 @@ include::{snippets}/httptrace/http-response.adoc[]
[[http-trace-retrieving-response-structure]]
=== Response Structure
The response contains details of the traced HTTP request-response exchanges.
The following table describes the structure of the response:

@ -1,13 +1,11 @@
[[info]]
= Info (`info`)
The `info` endpoint provides general information about the application.
[[info-retrieving]]
== Retrieving the Info
To retrieve the information about the application, make a `GET` request to `/actuator/info`, as shown in the following curl-based example:
include::{snippets}/info/curl-request.adoc[]
@ -20,7 +18,6 @@ include::{snippets}/info/http-response.adoc[]
[[info-retrieving-response-structure]]
=== Response Structure
The response contains general information about the application.
Each section of the response is contributed by an `InfoContributor`.
Spring Boot provides `build` and `git` contributions.
@ -29,7 +26,6 @@ Spring Boot provides `build` and `git` contributions.
[[info-retrieving-response-structure-build]]
==== Build Response Structure
The following table describe the structure of the `build` section of the response:
[cols="2,1,3"]
@ -39,7 +35,6 @@ include::{snippets}/info/response-fields-beneath-build.adoc[]
[[info-retrieving-response-structure-git]]
==== Git Response Structure
The following table describes the structure of the `git` section of the response:
[cols="2,1,3"]

@ -1,6 +1,5 @@
[[integrationgraph]]
= Spring Integration graph (`integrationgraph`)
The `integrationgraph` endpoint exposes a graph containing all Spring Integration components.

@ -1,13 +1,11 @@
[[liquibase]]
= Liquibase (`liquibase`)
The `liquibase` endpoint provides information about database change sets applied by Liquibase.
[[liquibase-retrieving]]
== Retrieving the Changes
To retrieve the changes, make a `GET` request to `/actuator/liquibase`, as shown in the following curl-based example:
include::{snippets}/liquibase/curl-request.adoc[]
@ -20,7 +18,6 @@ include::{snippets}/liquibase/http-response.adoc[]
[[liquibase-retrieving-response-structure]]
=== Response Structure
The response contains details of the application's Liquibase change sets.
The following table describes the structure of the response:

@ -1,13 +1,11 @@
[[log-file]]
= Log File (`logfile`)
The `logfile` endpoint provides access to the contents of the application's log file.
[[logfile-retrieving]]
== Retrieving the Log File
To retrieve the log file, make a `GET` request to `/actuator/logfile`, as shown in the following curl-based example:
include::{snippets}/logfile/entire/curl-request.adoc[]
@ -20,7 +18,6 @@ include::{snippets}/logfile/entire/http-response.adoc[]
[[logfile-retrieving-part]]
== Retrieving Part of the Log File
NOTE: Retrieving part of the log file is not supported when using Jersey.
To retrieve part of the log file, make a `GET` request to `/actuator/logfile` by using the `Range` header, as shown in the following curl-based example:

@ -1,13 +1,11 @@
[[loggers]]
= Loggers (`loggers`)
The `loggers` endpoint provides access to the application's loggers and the configuration of their levels.
[[loggers-all]]
== Retrieving All Loggers
To retrieve the application's loggers, make a `GET` request to `/actuator/loggers`, as shown in the following curl-based example:
include::{snippets}/loggers/all/curl-request.adoc[]
@ -20,7 +18,6 @@ include::{snippets}/loggers/all/http-response.adoc[]
[[loggers-all-response-structure]]
=== Response Structure
The response contains details of the application's loggers.
The following table describes the structure of the response:
@ -31,7 +28,6 @@ include::{snippets}/loggers/all/response-fields.adoc[]
[[loggers-single]]
== Retrieving a Single Logger
To retrieve a single logger, make a `GET` request to `/actuator/loggers/{logger.name}`, as shown in the following curl-based example:
include::{snippets}/loggers/single/curl-request.adoc[]
@ -45,7 +41,6 @@ include::{snippets}/loggers/single/http-response.adoc[]
[[loggers-single-response-structure]]
=== Response Structure
The response contains details of the requested logger.
The following table describes the structure of the response:
@ -56,7 +51,6 @@ include::{snippets}/loggers/single/response-fields.adoc[]
[[loggers-group]]
== Retrieving a Single Group
To retrieve a single group, make a `GET` request to `/actuator/loggers/{group.name}`,
as shown in the following curl-based example:
@ -71,7 +65,6 @@ include::{snippets}/loggers/group/http-response.adoc[]
[[loggers-group-response-structure]]
=== Response Structure
The response contains details of the requested group.
The following table describes the structure of the response:
@ -82,7 +75,6 @@ include::{snippets}/loggers/group/response-fields.adoc[]
[[loggers-setting-level]]
== Setting a Log Level
To set the level of a logger, make a `POST` request to `/actuator/loggers/{logger.name}` with a JSON body that specifies the configured level for the logger, as shown in the following curl-based example:
include::{snippets}/loggers/set/curl-request.adoc[]
@ -93,7 +85,6 @@ The preceding example sets the `configuredLevel` of the `com.example` logger to
[[loggers-setting-level-request-structure]]
=== Request Structure
The request specifies the desired level of the logger.
The following table describes the structure of the request:
@ -104,7 +95,6 @@ include::{snippets}/loggers/set/request-fields.adoc[]
[[loggers-group-setting-level]]
== Setting a Log Level for a Group
To set the level of a logger, make a `POST` request to `/actuator/loggers/{group.name}` with a JSON body that specifies the configured level for the logger group, as shown in the following curl-based example:
include::{snippets}/loggers/setGroup/curl-request.adoc[]
@ -115,7 +105,6 @@ The preceding example sets the `configuredLevel` of the `test` logger group to `
[[loggers-group-setting-level-request-structure]]
=== Request Structure
The request specifies the desired level of the logger group.
The following table describes the structure of the request:
@ -126,7 +115,6 @@ include::{snippets}/loggers/set/request-fields.adoc[]
[[loggers-clearing-level]]
== Clearing a Log Level
To clear the level of a logger, make a `POST` request to `/actuator/loggers/{logger.name}` with a JSON body containing an empty object, as shown in the following curl-based example:
include::{snippets}/loggers/clear/curl-request.adoc[]

@ -1,13 +1,11 @@
[[mappings]]
= Mappings (`mappings`)
The `mappings` endpoint provides information about the application's request mappings.
[[mappings-retrieving]]
== Retrieving the Mappings
To retrieve the mappings, make a `GET` request to `/actuator/mappings`, as shown in the following curl-based example:
include::{snippets}/mappings/curl-request.adoc[]
@ -20,7 +18,6 @@ include::{snippets}/mappings/http-response.adoc[]
[[mappings-retrieving-response-structure]]
=== Response Structure
The response contains details of the application's mappings.
The items found in the response depend on the type of web application (reactive or Servlet-based).
The following table describes the structure of the common elements of the response:
@ -31,9 +28,9 @@ include::{snippets}/mappings/response-fields.adoc[]
The entries that may be found in `contexts.*.mappings` are described in the following sections.
[[mappings-retrieving-response-structure-dispatcher-servlets]]
=== Dispatcher Servlets Response Structure
When using Spring MVC, the response contains details of any `DispatcherServlet` request mappings beneath `contexts.*.mappings.dispatcherServlets`.
The following table describes the structure of this section of the response:
@ -44,7 +41,6 @@ include::{snippets}/mappings/response-fields-dispatcher-servlets.adoc[]
[[mappings-retrieving-response-structure-servlets]]
=== Servlets Response Structure
When using the Servlet stack, the response contains details of any `Servlet` mappings beneath `contexts.*.mappings.servlets`.
The following table describes the structure of this section of the response:
@ -55,7 +51,6 @@ include::{snippets}/mappings/response-fields-servlets.adoc[]
[[mappings-retrieving-response-structure-servlet-filters]]
=== Servlet Filters Response Structure
When using the Servlet stack, the response contains details of any `Filter` mappings beneath `contexts.*.mappings.servletFilters`.
The following table describes the structure of this section of the response:
@ -66,7 +61,6 @@ include::{snippets}/mappings/response-fields-servlet-filters.adoc[]
[[mappings-retrieving-response-structure-dispatcher-handlers]]
=== Dispatcher Handlers Response Structure
When using Spring WebFlux, the response contains details of any `DispatcherHandler` request mappings beneath `contexts.*.mappings.dispatcherHandlers`.
The following table describes the structure of this section of the response:

@ -1,13 +1,11 @@
[[metrics]]
= Metrics (`metrics`)
The `metrics` endpoint provides access to application metrics.
[[metrics-retrieving-names]]
== Retrieving Metric Names
To retrieve the names of the available metrics, make a `GET` request to `/actuator/metrics`, as shown in the following curl-based example:
include::{snippets}/metrics/names/curl-request.adoc[]
@ -20,7 +18,6 @@ include::{snippets}/metrics/names/http-response.adoc[]
[[metrics-retrieving-names-response-structure]]
=== Response Structure
The response contains details of the metric names.
The following table describes the structure of the response:
@ -31,7 +28,6 @@ include::{snippets}/metrics/names/response-fields.adoc[]
[[metrics-retrieving-metric]]
== Retrieving a Metric
To retrieve a metric, make a `GET` request to `/actuator/metrics/{metric.name}`, as shown in the following curl-based example:
include::{snippets}/metrics/metric/curl-request.adoc[]
@ -45,7 +41,6 @@ include::{snippets}/metrics/metric/http-response.adoc[]
[[metrics-retrieving-metric-query-parameters]]
=== Query Parameters
The endpoint uses query parameters to <<metrics-drilling-down,drill down>> into a metric by using its tags.
The following table shows the single supported query parameter:
@ -56,16 +51,15 @@ include::{snippets}/metrics/metric-with-tags/request-parameters.adoc[]
[[metrics-retrieving-metric-response-structure]]
=== Response structure
The response contains details of the metric.
The following table describes the structure of the response:
include::{snippets}/metrics/metric/response-fields.adoc[]
[[metrics-drilling-down]]
== Drilling Down
To drill down into a metric, make a `GET` request to `/actuator/metrics/{metric.name}` using the `tag` query parameter, as shown in the following curl-based example:
include::{snippets}/metrics/metric-with-tags/curl-request.adoc[]

@ -1,13 +1,11 @@
[[prometheus]]
= Prometheus (`prometheus`)
The `prometheus` endpoint provides Spring Boot application's metrics in the format required for scraping by a Prometheus server.
[[prometheus-retrieving]]
== Retrieving All Metrics
To retrieve all metrics, make a `GET` request to `/actuator/prometheus`, as shown in the following curl-based example:
include::{snippets}/prometheus/all/curl-request.adoc[]
@ -29,7 +27,6 @@ include::{snippets}/prometheus/openmetrics/http-response.adoc[]
[[prometheus-retrieving-query-parameters]]
=== Query Parameters
The endpoint uses query parameters to limit the samples that it returns.
The following table shows the supported query parameters:
@ -40,7 +37,6 @@ include::{snippets}/prometheus/names/request-parameters.adoc[]
[[prometheus-retrieving-names]]
== Retrieving Filtered Metrics
To retrieve metrics matching specific names, make a `GET` request to `/actuator/prometheus` with the `includedNames` query parameter, as shown in the following curl-based example:
include::{snippets}/prometheus/names/curl-request.adoc[]

@ -1,13 +1,11 @@
[[quartz]]
= Quartz (`quartz`)
The `quartz` endpoint provides information about jobs and triggers that are managed by the Quartz Scheduler.
[[quartz-report]]
== Retrieving Registered Groups
Jobs and triggers are managed in groups.
To retrieve the list of registered job and trigger groups, make a `GET` request to `/actuator/quartz`, as shown in the following curl-based example:
@ -31,7 +29,6 @@ include::{snippets}/quartz/report/response-fields.adoc[]
[[quartz-job-groups]]
== Retrieving Registered Job Names
To retrieve the list of registered job names, make a `GET` request to `/actuator/quartz/jobs`, as shown in the following curl-based example:
include::{snippets}/quartz/jobs/curl-request.adoc[]
@ -41,6 +38,7 @@ The resulting response is similar to the following:
include::{snippets}/quartz/jobs/http-response.adoc[]
[[quartz-job-groups-response-structure]]
=== Response Structure
The response contains the registered job names for each group.
@ -53,7 +51,6 @@ include::{snippets}/quartz/jobs/response-fields.adoc[]
[[quartz-trigger-groups]]
== Retrieving Registered Trigger Names
To retrieve the list of registered trigger names, make a `GET` request to `/actuator/quartz/triggers`, as shown in the following curl-based example:
include::{snippets}/quartz/triggers/curl-request.adoc[]
@ -76,7 +73,6 @@ include::{snippets}/quartz/triggers/response-fields.adoc[]
[[quartz-job-group]]
== Retrieving Overview of a Job Group
To retrieve an overview of the jobs in a particular group, make a `GET` request to `/actuator/quartz/jobs/\{groupName}`, as shown in the following curl-based example:
include::{snippets}/quartz/job-group/curl-request.adoc[]
@ -125,7 +121,6 @@ include::{snippets}/quartz/trigger-group/response-fields.adoc[]
[[quartz-job]]
== Retrieving Details of a Job
To retrieve the details about a particular job, make a `GET` request to `/actuator/quartz/jobs/\{groupName}/\{jobName}`, as shown in the following curl-based example:
include::{snippets}/quartz/job-details/curl-request.adoc[]
@ -137,9 +132,10 @@ include::{snippets}/quartz/job-details/http-response.adoc[]
If a key in the data map is identified as sensitive, its value is sanitized.
[[quartz-job-response-structure]]
=== Response Structure
The response contains the full details of a job including a summary of the triggers associated with it, if any.
The triggers are sorted by next fire time and priority.
The following table describes the structure of the response:
@ -148,9 +144,9 @@ The following table describes the structure of the response:
include::{snippets}/quartz/job-details/response-fields.adoc[]
[[quartz-trigger]]
== Retrieving Details of a Trigger
To retrieve the details about a particular trigger, make a `GET` request to `/actuator/quartz/triggers/\{groupName}/\{triggerName}`, as shown in the following curl-based example:
include::{snippets}/quartz/trigger-details-cron/curl-request.adoc[]
@ -161,7 +157,6 @@ The preceding example retrieves the details of trigger identified by the `sample
[[quartz-trigger-common-response-structure]]
=== Common Response Structure
The response has a common structure and an additional object that is specific to the trigger's type.
There are five supported types:
@ -180,7 +175,6 @@ include::{snippets}/quartz/trigger-details-common/response-fields.adoc[]
[[quartz-trigger-cron-response-structure]]
=== Cron Trigger Response Structure
A cron trigger defines the cron expression that is used to determine when it has to fire.
The resulting response for such a trigger implementation is similar to the following:
@ -198,7 +192,6 @@ include::{snippets}/quartz/trigger-details-cron/response-fields.adoc[]
[[quartz-trigger-simple-response-structure]]
=== Simple Trigger Response Structure
A simple trigger is used to fire a Job at a given moment in time, and optionally repeated at a specified interval.
The resulting response for such a trigger implementation is similar to the following:
@ -216,7 +209,6 @@ include::{snippets}/quartz/trigger-details-simple/response-fields.adoc[]
[[quartz-trigger-daily-time-interval-response-structure]]
=== Daily Time Interval Trigger Response Structure
A daily time interval trigger is used to fire a Job based upon daily repeating time intervals.
The resulting response for such a trigger implementation is similar to the following:
@ -234,7 +226,6 @@ include::{snippets}/quartz/trigger-details-daily-time-interval/response-fields.a
[[quartz-trigger-calendar-interval-response-structure]]
=== Calendar Interval Trigger Response Structure
A calendar interval trigger is used to fire a Job based upon repeating calendar time intervals.
The resulting response for such a trigger implementation is similar to the following:
@ -252,7 +243,6 @@ include::{snippets}/quartz/trigger-details-calendar-interval/response-fields.ado
[[quartz-trigger-custom-response-structure]]
=== Custom Trigger Response Structure
A custom trigger is any other implementation.
The resulting response for such a trigger implementation is similar to the following:

@ -1,13 +1,11 @@
[[scheduled-tasks]]
= Scheduled Tasks (`scheduledtasks`)
The `scheduledtasks` endpoint provides information about the application's scheduled tasks.
[[scheduled-tasks-retrieving]]
== Retrieving the Scheduled Tasks
To retrieve the scheduled tasks, make a `GET` request to `/actuator/scheduledtasks`, as shown in the following curl-based example:
include::{snippets}/scheduled-tasks/curl-request.adoc[]
@ -20,7 +18,6 @@ include::{snippets}/scheduled-tasks/http-response.adoc[]
[[scheduled-tasks-retrieving-response-structure]]
=== Response Structure
The response contains details of the application's scheduled tasks.
The following table describes the structure of the response:

@ -1,13 +1,11 @@
[[sessions]]
= Sessions (`sessions`)
The `sessions` endpoint provides information about the application's HTTP sessions that are managed by Spring Session.
[[sessions-retrieving]]
== Retrieving Sessions
To retrieve the sessions, make a `GET` request to `/actuator/sessions`, as shown in the following curl-based example:
include::{snippets}/sessions/username/curl-request.adoc[]
@ -21,7 +19,6 @@ include::{snippets}/sessions/username/http-response.adoc[]
[[sessions-retrieving-query-parameters]]
=== Query Parameters
The endpoint uses query parameters to limit the sessions that it returns.
The following table shows the single required query parameter:
@ -32,7 +29,6 @@ include::{snippets}/sessions/username/request-parameters.adoc[]
[[sessions-retrieving-response-structure]]
=== Response Structure
The response contains details of the matching sessions.
The following table describes the structure of the response:
@ -43,7 +39,6 @@ include::{snippets}/sessions/username/response-fields.adoc[]
[[sessions-retrieving-id]]
== Retrieving a Single Session
To retrieve a single session, make a `GET` request to `/actuator/sessions/\{id}`, as shown in the following curl-based example:
include::{snippets}/sessions/id/curl-request.adoc[]
@ -57,7 +52,6 @@ include::{snippets}/sessions/id/http-response.adoc[]
[[sessions-retrieving-id-response-structure]]
=== Response Structure
The response contains details of the requested session.
The following table describes the structure of the response:
@ -68,7 +62,6 @@ include::{snippets}/sessions/id/response-fields.adoc[]
[[sessions-deleting]]
== Deleting a Session
To delete a session, make a `DELETE` request to `/actuator/sessions/\{id}`, as shown in the following curl-based example:
include::{snippets}/sessions/delete/curl-request.adoc[]

@ -1,13 +1,11 @@
[[shutdown]]
= Shutdown (`shutdown`)
The `shutdown` endpoint is used to shut down the application.
[[shutdown-shutting-down]]
== Shutting Down the Application
To shut down the application, make a `POST` request to `/actuator/shutdown`, as shown in the following curl-based example:
include::{snippets}/shutdown/curl-request.adoc[]
@ -20,7 +18,6 @@ include::{snippets}/shutdown/http-response.adoc[]
[[shutdown-shutting-down-response-structure]]
=== Response Structure
The response contains details of the result of the shutdown request.
The following table describes the structure of the response:

@ -1,17 +1,17 @@
[[startup]]
= Application Startup (`startup`)
The `startup` endpoint provides information about the application's startup sequence.
[[startup-retrieving]]
== Retrieving the Application Startup steps
The application startup steps can either be retrieved as a snapshot (`GET`) or drained from the buffer (`POST`).
[[startup-retrieving-snapshot]]
=== Retrieving a snapshot of the Application Startup steps
To retrieve the steps recorded so far during the application startup phase, make a `GET` request to `/actuator/startup`, as shown in the following curl-based example:
include::{snippets}/startup-snapshot/curl-request.adoc[]
@ -21,9 +21,9 @@ The resulting response is similar to the following:
include::{snippets}/startup-snapshot/http-response.adoc[]
[[startup-retrieving-drain]]
== Draining the Application Startup steps
To drain and return the steps recorded so far during the application startup phase, make a `POST` request to `/actuator/startup`, as shown in the following curl-based example:
include::{snippets}/startup/curl-request.adoc[]
@ -32,9 +32,10 @@ The resulting response is similar to the following:
include::{snippets}/startup/http-response.adoc[]
[[startup-retrieving-response-structure]]
=== Response Structure
The response contains details of the application startup steps.
The following table describes the structure of the response:

@ -1,13 +1,11 @@
[[threaddump]]
= Thread Dump (`threaddump`)
The `threaddump` endpoint provides a thread dump from the application's JVM.
[[threaddump-retrieving-json]]
== Retrieving the Thread Dump as JSON
To retrieve the thread dump as JSON, make a `GET` request to `/actuator/threaddump` with an appropriate `Accept` header, as shown in the following curl-based example:
include::{snippets}/threaddump/json/curl-request.adoc[]
@ -20,7 +18,6 @@ include::{snippets}/threaddump/json/http-response.adoc[]
[[threaddump-retrieving-json-response-structure]]
=== Response Structure
The response contains details of the JVM's threads.
The following table describes the structure of the response:
@ -31,7 +28,6 @@ include::{snippets}/threaddump/json/response-fields.adoc[]
[[threaddump-retrieving-text]]
== Retrieving the Thread Dump as Text
To retrieve the thread dump as text, make a `GET` request to `/actuator/threaddump` that
accepts `text/plain`, as shown in the following curl-based example:

@ -1,5 +1,6 @@
[[spring-boot-actuator-web-api-documentation]]
= Spring Boot Actuator Web API Documentation
Andy Wilkinson
Andy Wilkinson, Stephane Nicoll
:doctype: book
:toc: left
:toclevels: 4
@ -9,13 +10,14 @@ Andy Wilkinson
:docinfo: shared,private
:attribute-missing: warn
This API documentation describes Spring Boot Actuators web endpoints.
[[overview]]
== Overview
Before you proceed, you should read the following topics:
* <<overview-endpoint-urls>>
@ -23,9 +25,10 @@ Before you proceed, you should read the following topics:
NOTE: In order to get the correct JSON responses documented below, Jackson must be available.
[[overview-endpoint-urls]]
=== URLs
By default, all web endpoints are available beneath the path `/actuator` with URLs of
the form `/actuator/\{id}`. The `/actuator` base path can be configured by using the
`management.endpoints.web.base-path` property, as shown in the following example:
@ -43,7 +46,6 @@ The preceding `application.properties` example changes the form of the endpoint
[[overview-timestamps]]
=== Timestamps
All timestamps that are consumed by the endpoints, either as query parameters or in the
request body, must be formatted as an offset date and time as specified in
https://en.wikipedia.org/wiki/ISO_8601[ISO 8601].
@ -51,26 +53,49 @@ https://en.wikipedia.org/wiki/ISO_8601[ISO 8601].
include::endpoints/auditevents.adoc[leveloffset=+1]
include::endpoints/beans.adoc[leveloffset=+1]
include::endpoints/caches.adoc[leveloffset=+1]
include::endpoints/conditions.adoc[leveloffset=+1]
include::endpoints/configprops.adoc[leveloffset=+1]
include::endpoints/env.adoc[leveloffset=+1]
include::endpoints/flyway.adoc[leveloffset=+1]
include::endpoints/health.adoc[leveloffset=+1]
include::endpoints/heapdump.adoc[leveloffset=+1]
include::endpoints/httptrace.adoc[leveloffset=+1]
include::endpoints/info.adoc[leveloffset=+1]
include::endpoints/integrationgraph.adoc[leveloffset=+1]
include::endpoints/liquibase.adoc[leveloffset=+1]
include::endpoints/logfile.adoc[leveloffset=+1]
include::endpoints/loggers.adoc[leveloffset=+1]
include::endpoints/mappings.adoc[leveloffset=+1]
include::endpoints/metrics.adoc[leveloffset=+1]
include::endpoints/prometheus.adoc[leveloffset=+1]
include::endpoints/quartz.adoc[leveloffset=+1]
include::endpoints/scheduledtasks.adoc[leveloffset=+1]
include::endpoints/sessions.adoc[leveloffset=+1]
include::endpoints/shutdown.adoc[leveloffset=+1]
include::endpoints/startup.adoc[leveloffset=+1]
include::endpoints/threaddump.adoc[leveloffset=+1]

@ -1,20 +0,0 @@
@import url("spring.css");
div .switch {
margin-left: 8px;
border-color: #406A2A;
border-radius: 4px 4px 0 0;
}
div .switch--item {
color: #406A2A;
background-color: transparent;
}
div .switch--item.selected {
background-color: #406A2A;
}
div .switch--item:not(:first-child) {
border-color: #406A2A;
}

@ -85,7 +85,6 @@ For example, when the `java` plugin is applied a task for building an executable
A typical Spring Boot project will apply the {groovy-plugin}[`groovy`], {java-plugin}[`java`], or {kotlin-plugin}[`org.jetbrains.kotlin.jvm`] plugin as a minimum and also use the {dependency-management-plugin}[`io.spring.dependency-management`] plugin or Gradle's native bom support for dependency management.
For example:
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
.Groovy
----

@ -1,3 +1,4 @@
[[spring-boot-gradle-plugin-documentation]]
= Spring Boot Gradle Plugin Reference Guide
Andy Wilkinson, Scott Frederick
:doctype: book
@ -9,7 +10,6 @@ Andy Wilkinson, Scott Frederick
:hide-uri-scheme:
:docinfo: shared,private
:attribute-missing: warn
:dependency-management-plugin: https://github.com/spring-gradle-plugins/dependency-management-plugin
:dependency-management-plugin-documentation: https://docs.spring.io/dependency-management-plugin/docs/current/reference/html/
:gradle-userguide: https://docs.gradle.org/current/userguide
@ -39,6 +39,7 @@ Andy Wilkinson, Scott Frederick
:paketo-java-reference: {paketo-reference}/buildpacks/language-family-buildpacks/java
[[introduction]]
== Introduction
The Spring Boot Gradle Plugin provides Spring Boot support in https://gradle.org[Gradle].
@ -48,10 +49,17 @@ Spring Boot's Gradle plugin requires Gradle 6.8, 6.9, or 7.x and can be used wit
In addition to this user guide, {api-documentation}[API documentation] is also available.
include::getting-started.adoc[]
include::managing-dependencies.adoc[]
include::packaging.adoc[]
include::packaging-oci-image.adoc[]
include::publishing.adoc[]
include::running.adoc[]
include::integrating-with-actuator.adoc[]
include::reacting.adoc[]

@ -2,6 +2,7 @@
== Integrating with Actuator
[[integrating-with-actuator-build-info]]
=== Generating Build Information
Spring Boot Actuator's `info` endpoint automatically publishes information about your build in the presence of a `META-INF/build-info.properties` file.
@ -20,7 +21,6 @@ include::../gradle/integrating-with-actuator/build-info-basic.gradle[tags=build-
include::../gradle/integrating-with-actuator/build-info-basic.gradle.kts[tags=build-info]
----
This will configure a {build-info-javadoc}[`BuildInfo`] task named `bootBuildInfo` and, if it exists, make the Java plugin's `classes` task depend upon it.
The task's destination directory will be `META-INF` in the output directory of the main source set's resources (typically `build/resources/main`).
@ -61,7 +61,6 @@ include::../gradle/integrating-with-actuator/build-info-custom-values.gradle[tag
include::../gradle/integrating-with-actuator/build-info-custom-values.gradle.kts[tags=custom-values]
----
The default value for `build.time` is the instant at which the project is being built.
A side-effect of this is that the task will never be up-to-date.
As a result, builds will take longer as more tasks, including the project's tests, will have to be executed.

@ -53,7 +53,6 @@ Overriding versions may cause compatibility issues and should be done with care.
[[managing-dependencies-dependency-management-plugin-using-in-isolation]]
==== Using Spring Boot's Dependency Management in Isolation
Spring Boot's dependency management can be used in a project without applying Spring Boot's plugin to that project.
The `SpringBootPlugin` class provides a `BOM_COORDINATES` constant that can be used to import the bom without having to know its group ID, artifact ID, or version.
@ -114,7 +113,6 @@ include::../gradle/managing-dependencies/configure-bom.gradle[tags=configure-bom
include::../gradle/managing-dependencies/configure-bom.gradle.kts[tags=configure-bom]
----
The Kotlin code above is a bit awkward.
That's because we're using the imperative way of applying the dependency management plugin.

@ -11,6 +11,8 @@ The task is automatically created when the `java` or `war` plugin is applied and
NOTE: The `bootBuildImage` task can not be used with a <<packaging-executable-configuring-launch-script, fully executable Spring Boot archive>> that includes a launch script.
Disable launch script configuration in the `bootJar` task when building a jar file that is intended to be used with `bootBuildImage`.
[[build-image-docker-daemon]]
=== Docker Daemon
The `bootBuildImage` task requires access to a Docker daemon.

@ -37,7 +37,6 @@ include::../gradle/packaging/war-container-dependency.gradle[tags=dependencies]
include::../gradle/packaging/war-container-dependency.gradle.kts[tags=dependencies]
----
This ensures that they are package in the war file's `WEB-INF/lib-provided` directory from where they will not conflict with the external container's own classes.
NOTE: `providedRuntime` is preferred to Gradle's `compileOnly` configuration as, among other limitations, `compileOnly` dependencies are not on the test classpath so any web-based integration tests will fail.
@ -153,6 +152,7 @@ For example, `ExampleApplication` becomes `ExampleApplicationKt`.
If another name is defined using `@JvmName` then that name should be used.
[[packaging-executable-configuring-including-development-only-dependencies]]
==== Including Development-only Dependencies
By default all dependencies declared in the `developmentOnly` configuration will be excluded from an executable jar or war.
@ -193,7 +193,6 @@ include::../gradle/packaging/boot-jar-requires-unpack.gradle[tags=requires-unpac
include::../gradle/packaging/boot-jar-requires-unpack.gradle.kts[tags=requires-unpack]
----
For more control a closure can also be used.
The closure is passed a `FileTreeElement` and should return a `boolean` indicating whether or not unpacking is required.

@ -7,13 +7,9 @@ To use the Spring Boot Maven Plugin, include the appropriate XML in the `plugins
include::../maven/getting-started/pom.xml[tags=getting-started]
----
If you use a milestone or snapshot release, you also need to add the appropriate `pluginRepository` elements, as shown in the following listing:
[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
----
include::../maven/getting-started/plugin-repositories-pom.xml[tags=plugin-repositories]
----

@ -3,4 +3,3 @@
The Spring Boot Plugin has the following goals:
include::goals/overview.adoc[]

@ -1,3 +1,4 @@
[[spring-boot-maven-plugin-documentation]]
= Spring Boot Maven Plugin Documentation
Stephane Nicoll, Andy Wilkinson, Scott Frederick
:doctype: book
@ -9,7 +10,6 @@ Stephane Nicoll, Andy Wilkinson, Scott Frederick
:hide-uri-scheme:
:docinfo: shared,private
:attribute-missing: warn
:buildpacks-reference: https://buildpacks.io/docs
:spring-boot-docs: https://docs.spring.io/spring-boot/docs/{gradle-project-version}
:spring-boot-api: {spring-boot-docs}/api/org/springframework/boot
@ -19,18 +19,26 @@ Stephane Nicoll, Andy Wilkinson, Scott Frederick
:paketo-java-reference: {paketo-reference}/buildpacks/language-family-buildpacks/java
[[introduction]]
== Introduction
The Spring Boot Maven Plugin provides Spring Boot support in https://maven.org[Apache Maven].
It allows you to package executable jar or war archives, run Spring Boot applications, generate build information and start your Spring Boot application prior to running integration tests.
include::getting-started.adoc[]
include::using.adoc[]
include::goals.adoc[]
include::packaging.adoc[]
include::packaging-oci-image.adoc[]
include::running.adoc[]
include::integration-tests.adoc[]
include::build-info.adoc[]
include::help.adoc[]
include::help.adoc[]

@ -1,6 +1,5 @@
[[repackage]]
== Packaging Executable Archives
The plugin can create executable archives (jar files and war files) that contain all of an application's dependencies and can then be run with `java -jar`.
Packaging an executable archive is performed by the `repackage` goal, as shown in the following example:
@ -71,6 +70,7 @@ include::../maven/packaging/disable-layers-pom.xml[tags=disable-layers]
----
[[repackage-layers-configuration]]
==== Custom Layers Configuration
Depending on your application, you may want to tune how layers are created and add new ones.
@ -89,8 +89,6 @@ The following example shows how the default ordering described above can be defi
include::../maven/packaging/layers.xml[tags=layers]
----
The `layers` XML format is defined in three sections:
* The `<application>` block defines how the application classes and resources should be layered.
@ -151,7 +149,6 @@ In that setup, only the configuration should be specified, as shown in the follo
include::../maven/packaging/repackage-configuration-pom.xml[tags=repackage-configuration]
----
This configuration will generate two artifacts: the original one and the repackaged counter part produced by the repackage goal.
Both will be installed/deployed transparently.
@ -163,7 +160,6 @@ The following configuration installs/deploys a single `task` classified artifact
include::../maven/packaging/classified-artifact-pom.xml[tags=classified-artifact]
----
As both the `maven-jar-plugin` and the `spring-boot-maven-plugin` runs at the same phase, it is important that the jar plugin is defined first (so that it runs before the repackage goal).
Again, if you are using `spring-boot-starter-parent`, this can be simplified as follows:

@ -26,7 +26,6 @@ To enable it, just add the following dependency to your project:
include::../maven/running/devtools-pom.xml[tags=devtools]
----
When `devtools` is running, it detects change when you recompile your application and automatically refreshes it.
This works for not only resources but code as well.
It also provides a LiveReload server so that it can automatically trigger a browser refresh whenever things change.
@ -176,6 +175,3 @@ The profiles to enable can be specified on the command line as well, make sure t
----
$ mvn spring-boot:run -Dspring-boot.run.profiles=local,dev
----

Loading…
Cancel
Save