Polish asciidoc formatting
This commit is contained in:
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…
Reference in New Issue