Commit 33c6c600 authored by Phillip Webb's avatar Phillip Webb

Split up adoc files

Closes gh-23254
parent bb8188b6
......@@ -181,33 +181,33 @@ task aggregatedJavadoc(type: Javadoc) {
task documentTestSlices(type: org.springframework.boot.build.test.autoconfigure.DocumentTestSlices) {
testSlices = configurations.testSlices
outputFile = file("${buildDir}/docs/generated/test-slice-auto-configuration.adoc")
outputFile = file("${buildDir}/docs/generated/test-auto-configuration/documented-slices.adoc")
}
task documentStarters(type: org.springframework.boot.build.starters.DocumentStarters) {
outputDir = file("${buildDir}/docs/generated/starters/")
outputDir = file("${buildDir}/docs/generated/using/starters/")
}
task documentAutoConfigurationClasses(type: org.springframework.boot.build.autoconfigure.DocumentAutoConfigurationClasses) {
autoConfiguration = configurations.autoConfiguration
outputDir = file("${buildDir}/docs/generated/auto-configuration-classes/")
outputDir = file("${buildDir}/docs/generated/auto-configuration-classes/documented-auto-configuration-classes/")
}
task documentDependencyVersions(type: org.springframework.boot.build.constraints.DocumentConstrainedVersions) {
dependsOn dependencyVersions
constrainedVersions.set(providers.provider { dependencyVersions.constrainedVersions })
outputFile = file("${buildDir}/docs/generated/generated-dependency-versions.adoc")
outputFile = file("${buildDir}/docs/generated/dependency-versions/documented-coordinates.adoc")
}
task documentVersionProperties(type: org.springframework.boot.build.constraints.DocumentVersionProperties) {
dependsOn dependencyVersions
versionProperties.set(providers.provider { dependencyVersions.versionProperties})
outputFile = file("${buildDir}/docs/generated/generated-version-properties.adoc")
outputFile = file("${buildDir}/docs/generated/dependency-versions/documented-properties.adoc")
}
task documentConfigurationProperties(type: org.springframework.boot.build.context.properties.DocumentConfigurationProperties) {
configurationPropertyMetadata = configurations.configurationProperties
outputDir = file("${buildDir}/docs/generated/config-docs/")
outputDir = file("${buildDir}/docs/generated/application-properties/documented-application-properties/")
}
tasks.withType(org.asciidoctor.gradle.jvm.AbstractAsciidoctorTask) {
......
This source diff could not be displayed because it is too large. You can view the blob instead.
[[actuator.auditing]]
== Auditing
Once Spring Security is in play, Spring Boot Actuator has a flexible audit framework that publishes events (by default, "`authentication success`", "`failure`" and "`access denied`" exceptions).
This feature can be very useful for reporting and for implementing a lock-out policy based on authentication failures.
Auditing can be enabled by providing a bean of type `AuditEventRepository` in your application's configuration.
For convenience, Spring Boot offers an `InMemoryAuditEventRepository`.
`InMemoryAuditEventRepository` has limited capabilities and we recommend using it only for development environments.
For production environments, consider creating your own alternative `AuditEventRepository` implementation.
[[actuator.auditing.custom]]
=== Custom Auditing
To customize published security events, you can provide your own implementations of `AbstractAuthenticationAuditListener` and `AbstractAuthorizationAuditListener`.
You can also use the audit services for your own business events.
To do so, either inject the `AuditEventRepository` bean into your own components and use that directly or publish an `AuditApplicationEvent` with the Spring `ApplicationEventPublisher` (by implementing `ApplicationEventPublisherAware`).
[[actuator.cloud-foundry]]
== Cloud Foundry Support
Spring Boot's actuator module includes additional support that is activated when you deploy to a compatible Cloud Foundry instance.
The `/cloudfoundryapplication` path provides an alternative secured route to all `@Endpoint` beans.
The extended support lets Cloud Foundry management UIs (such as the web application that you can use to view deployed applications) be augmented with Spring Boot actuator information.
For example, an application status page may include full health information instead of the typical "`running`" or "`stopped`" status.
NOTE: The `/cloudfoundryapplication` path is not directly accessible to regular users.
In order to use the endpoint, a valid UAA token must be passed with the request.
[[actuator.cloud-foundry.disable]]
=== Disabling Extended Cloud Foundry Actuator Support
If you want to fully disable the `/cloudfoundryapplication` endpoints, you can add the following setting to your `application.properties` file:
.application.properties
[source,yaml,indent=0,configprops,configblocks]
----
management:
cloudfoundry:
enabled: false
----
[[actuator.cloud-foundry.ssl]]
=== Cloud Foundry Self-signed Certificates
By default, the security verification for `/cloudfoundryapplication` endpoints makes SSL calls to various Cloud Foundry services.
If your Cloud Foundry UAA or Cloud Controller services use self-signed certificates, you need to set the following property:
.application.properties
[source,yaml,indent=0,configprops,configblocks]
----
management:
cloudfoundry:
skip-ssl-validation: true
----
[[actuator.cloud-foundry.custom-context-path]]
=== Custom Context Path
If the server's context-path has been configured to anything other than `/`, the Cloud Foundry endpoints will not be available at the root of the application.
For example, if `server.servlet.context-path=/app`, Cloud Foundry endpoints will be available at `/app/cloudfoundryapplication/*`.
If you expect the Cloud Foundry endpoints to always be available at `/cloudfoundryapplication/*`, regardless of the server's context-path, you will need to explicitly configure that in your application.
The configuration will differ depending on the web server in use.
For Tomcat, the following configuration can be added:
[source,java,indent=0]
----
include::{include-productionreadyfeatures}/cloudfoundry/CloudFoundryCustomContextPathConfiguration.java[tag=*]
----
[[actuator.enabling]]
== Enabling Production-ready Features
The {spring-boot-code}/spring-boot-project/spring-boot-actuator[`spring-boot-actuator`] module provides all of Spring Boot's production-ready features.
The recommended way to enable the features is to add a dependency on the `spring-boot-starter-actuator` '`Starter`'.
.Definition of Actuator
****
An actuator is a manufacturing term that refers to a mechanical device for moving or controlling something.
Actuators can generate a large amount of motion from a small change.
****
To add the actuator to a Maven based project, add the following '`Starter`' dependency:
[source,xml,indent=0]
----
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
</dependencies>
----
For Gradle, use the following declaration:
[source,groovy,indent=0]
----
dependencies {
implementation 'org.springframework.boot:spring-boot-starter-actuator'
}
----
[[actuator.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 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.
To Take full control over endpoints registration in the JMX domain, consider registering your own `EndpointObjectNameFactory` implementation.
[[actuator.jmx.custom-mbean-names]]
=== Customizing MBean Names
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 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,yaml,indent=0,configprops,configblocks]
----
spring:
jmx:
unique-names: true
management:
endpoints:
jmx:
domain: "com.example.myapp"
----
[[actuator.jmx.disable-jmx-endpoints]]
=== Disabling JMX Endpoints
If you do not want to expose endpoints over JMX, you can set the configprop:management.endpoints.jmx.exposure.exclude[] property to `*`, as shown in the following example:
[source,yaml,indent=0,configprops,configblocks]
----
management:
endpoints:
jmx:
exposure:
exclude: "*"
----
[[actuator.jmx.jolokia]]
=== Using Jolokia for JMX over HTTP
Jolokia is a JMX-HTTP bridge that provides an alternative method of accessing JMX beans.
To use Jolokia, include a dependency to `org.jolokia:jolokia-core`.
For example, with Maven, you would add the following dependency:
[source,xml,indent=0]
----
<dependency>
<groupId>org.jolokia</groupId>
<artifactId>jolokia-core</artifactId>
</dependency>
----
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.
NOTE: The Jolokia endpoint exposes Jolokia's servlet as an actuator endpoint.
As a result, it is specific to servlet environments such as Spring MVC and Jersey.
The endpoint will not be available in a WebFlux application.
[[actuator.jmx.jolokia.customizing]]
==== Customizing Jolokia
Jolokia has a number of settings that you would traditionally configure by setting servlet parameters.
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,yaml,indent=0,configprops,configblocks]
----
management:
endpoint:
jolokia:
config:
debug: true
----
[[actuator.jmx.jolokia.disabling]]
==== Disabling Jolokia
If you use Jolokia but do not want Spring Boot to configure it, set the configprop:management.endpoint.jolokia.enabled[] property to `false`, as follows:
[source,yaml,indent=0,configprops,configblocks]
----
management:
endpoint:
jolokia:
enabled: false
----
[[actuator.loggers]]
== Loggers
Spring Boot Actuator includes the ability to view and configure the log levels of your application at runtime.
You can view either the entire list or an individual logger's configuration, which is made up of both the explicitly configured logging level as well as the effective logging level given to it by the logging framework.
These levels can be one of:
* `TRACE`
* `DEBUG`
* `INFO`
* `WARN`
* `ERROR`
* `FATAL`
* `OFF`
* `null`
`null` indicates that there is no explicit configuration.
[[actuator.loggers.configure]]
=== Configure a Logger
To configure a given logger, `POST` a partial entity to the resource's URI, as shown in the following example:
[source,json,indent=0]
----
{
"configuredLevel": "DEBUG"
}
----
TIP: To "`reset`" the specific level of the logger (and use the default configuration instead), you can pass a value of `null` as the `configuredLevel`.
[[actuator.monitoring]]
== Monitoring and Management over HTTP
If you are developing a web application, Spring Boot Actuator auto-configures all enabled endpoints to be exposed over HTTP.
The default convention is to use the `id` of the endpoint with a prefix of `/actuator` as the URL path.
For example, `health` is exposed as `/actuator/health`.
TIP: Actuator is supported natively with Spring MVC, Spring WebFlux, and Jersey.
If both Jersey and Spring MVC are available, Spring MVC will be used.
NOTE: Jackson is a required dependency in order to get the correct JSON responses as documented in the API documentation ({spring-boot-actuator-restapi-docs}[HTML] or {spring-boot-actuator-restapi-pdfdocs}[PDF]).
[[actuator.monitoring.customizing-management-server-context-path]]
=== 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 configprop:management.endpoints.web.base-path[] property to change the prefix for your management endpoint, as shown in the following example:
[source,yaml,indent=0,configprops,configblocks]
----
management:
endpoints:
web:
base-path: "/manage"
----
The preceding `application.properties` example changes the endpoint from `/actuator/\{id}` to `/manage/\{id}` (for example, `/manage/info`).
NOTE: Unless the management port has been configured to <<actuator#actuator.monitoring.customizing-management-server-port,expose endpoints by using a different HTTP port>>, `management.endpoints.web.base-path` is relative to `server.servlet.context-path` (Servlet web applications) or `spring.webflux.base-path` (reactive web applications).
If `management.server.port` is configured, `management.endpoints.web.base-path` is relative to `management.server.base-path`.
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`:
[source,yaml,indent=0,configprops,configblocks]
----
management:
endpoints:
web:
base-path: "/"
path-mapping:
health: "healthcheck"
----
[[actuator.monitoring.customizing-management-server-port]]
=== Customizing the Management Server Port
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 configprop:management.server.port[] property to change the HTTP port, as shown in the following example:
[source,yaml,indent=0,configprops,configblocks]
----
management:
server:
port: 8081
----
NOTE: On Cloud Foundry, applications only receive requests on port 8080 for both HTTP and TCP routing, by default.
If you want to use a custom management port on Cloud Foundry, you will need to explicitly set up the application's routes to forward traffic to the custom port.
[[actuator.monitoring.management-specific-ssl]]
=== Configuring Management-specific SSL
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,yaml,indent=0,configprops,configblocks]
----
server:
port: 8443
ssl:
enabled: true
key-store: "classpath:store.jks"
key-password: secret
management:
server:
port: 8080
ssl:
enabled: false
----
Alternatively, both the main server and the management server can use SSL but with different key stores, as follows:
[source,yaml,indent=0,configprops,configblocks]
----
server:
port: 8443
ssl:
enabled: true
key-store: "classpath:main.jks"
key-password: "secret"
management:
server:
port: 8080
ssl:
enabled: true
key-store: "classpath:management.jks"
key-password: "secret"
----
[[actuator.monitoring.customizing-management-server-address]]
=== Customizing the Management Server Address
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,yaml,indent=0,configprops,configblocks]
----
management:
server:
port: 8081
address: "127.0.0.1"
----
[[actuator.monitoring.disabling-http-endpoints]]
=== 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,yaml,indent=0,configprops,configblocks]
----
management:
server:
port: -1
----
This can be achieved using the configprop:management.endpoints.web.exposure.exclude[] property as well, as shown in the following example:
[source,yaml,indent=0,configprops,configblocks]
----
management:
endpoints:
web:
exposure:
exclude: "*"
----
[[actuator.process-monitoring]]
== Process Monitoring
In the `spring-boot` module, you can find two classes to create files that are often useful for process monitoring:
* `ApplicationPidFileWriter` creates a file containing the application PID (by default, in the application directory with a file name of `application.pid`).
* `WebServerPortFileWriter` creates a file (or files) containing the ports of the running web server (by default, in the application directory with a file name of `application.port`).
By default, these writers are not activated, but you can enable:
* <<actuator#actuator.process-monitoring.configuration,By Extending Configuration>>
* <<actuator#actuator.process-monitoring.programmatically>>
[[actuator.process-monitoring.configuration]]
=== Extending Configuration
In the `META-INF/spring.factories` file, you can activate the listener(s) that writes a PID file, as shown in the following example:
[indent=0]
----
org.springframework.context.ApplicationListener=\
org.springframework.boot.context.ApplicationPidFileWriter,\
org.springframework.boot.web.context.WebServerPortFileWriter
----
[[actuator.process-monitoring.programmatically]]
=== Programmatically
You can also activate a listener by invoking the `SpringApplication.addListeners(...)` method and passing the appropriate `Writer` object.
This method also lets you customize the file name and path in the `Writer` constructor.
[[actuator.tracing]]
== HTTP Tracing
HTTP Tracing can be enabled by providing a bean of type `HttpTraceRepository` in your application's configuration.
For convenience, Spring Boot offers an `InMemoryHttpTraceRepository` that stores traces for the last 100 request-response exchanges, by default.
`InMemoryHttpTraceRepository` is limited compared to other tracing solutions and we recommend using it only for development environments.
For production environments, use of a production-ready tracing or observability solution, such as Zipkin or Spring Cloud Sleuth, is recommended.
Alternatively, create your own `HttpTraceRepository` that meets your needs.
The `httptrace` endpoint can be used to obtain information about the request-response exchanges that are stored in the `HttpTraceRepository`.
[[actuator.tracing.custom]]
=== Custom HTTP tracing
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.
[[actuator.whats-next]]
== What to Read Next
You might want to read about graphing tools such as https://graphiteapp.org[Graphite].
Otherwise, you can continue on, to read about <<deployment#deployment, '`deployment options`'>> or jump ahead for some in-depth information about Spring Boot's _<<build-tool-plugins#build-tool-plugins, build tool plugins>>_.
[appendix]
[[application-properties]]
= Common Application properties
include::attributes.adoc[]
Various properties can be specified inside your `application.properties` file, inside your `application.yml` file, or as command line switches.
This appendix provides a list of common Spring Boot properties and references to the underlying classes that consume them.
TIP: Spring Boot provides various conversion mechanism with advanced value formatting, make sure to review <<features#features.external-config.typesafe-configuration-properties.conversion, the properties conversion section>>.
NOTE: Property contributions can come from additional jar files on your classpath, so you should not consider this an exhaustive list.
Also, you can define your own properties.
include::application-properties/core.adoc[]
include::application-properties/cache.adoc[]
include::application-properties/mail.adoc[]
include::application-properties/json.adoc[]
include::application-properties/data.adoc[]
include::application-properties/transaction.adoc[]
include::application-properties/data-migration.adoc[]
include::application-properties/integration.adoc[]
include::application-properties/web.adoc[]
include::application-properties/templating.adoc[]
include::application-properties/server.adoc[]
include::application-properties/security.adoc[]
include::application-properties/rsocket.adoc[]
include::application-properties/actuator.adoc[]
include::application-properties/devtools.adoc[]
include::application-properties/testing.adoc[]
[[application-properties.actuator]]
== Actuator Properties [[actuator-properties]]
include::documented-application-properties/actuator.adoc[]
[[application-properties.cache]]
== Cache Properties [[cache-properties]]
include::documented-application-properties/cache.adoc[]
[[application-properties.core]]
== Core Properties [[core-properties]]
include::documented-application-properties/core.adoc[]
[[application-properties.data-migration]]
== Data Migration Properties [[data-migration-properties]]
include::documented-application-properties/data-migration.adoc[]
[[application-properties.data]]
== Data Properties [[data-properties]]
include::documented-application-properties/data.adoc[]
[[application-properties.devtools]]
== Devtools Properties [[devtools-properties]]
include::documented-application-properties/devtools.adoc[]
[[application-properties.integration]]
== Integration Properties [[integration-properties]]
include::documented-application-properties/integration.adoc[]
[[application-properties.json]]
== JSON Properties [[json-properties]]
include::documented-application-properties/json.adoc[]
[[application-properties.mail]]
== Mail Properties [[mail-properties]]
include::documented-application-properties/mail.adoc[]
[[application-properties.rsocket]]
== RSocket Properties [[rsocket-properties]]
include::documented-application-properties/rsocket.adoc[]
[[application-properties.security]]
== Security Properties [[security-properties]]
include::documented-application-properties/security.adoc[]
[[application-properties.server]]
== Server Properties [[server-properties]]
include::documented-application-properties/server.adoc[]
[[application-properties.templating]]
== Templating Properties [[templating-properties]]
include::documented-application-properties/templating.adoc[]
[[application-properties.testing]]
== Testing Properties [[testing-properties]]
include::documented-application-properties/testing.adoc[]
[[application-properties.transaction]]
== Transaction Properties [[transaction-properties]]
include::documented-application-properties/transaction.adoc[]
[[application-properties.web]]
== Web Properties [[web-properties]]
include::documented-application-properties/web.adoc[]
......@@ -10,21 +10,17 @@
:hide-uri-scheme:
:docinfo: shared,private
:chomp: tags formatters headers packages
:spring-boot-artifactory-repo: snapshot
:github-tag: main
:spring-boot-version: current
:github-repo: spring-projects/spring-boot
:github-raw: https://raw.githubusercontent.com/{github-repo}/{github-tag}
:github-issues: https://github.com/{github-repo}/issues/
:github-wiki: https://github.com/{github-repo}/wiki
:include: ../main/java/org/springframework/boot/docs
:include: ../../main/java/org/springframework/boot/docs
:include-springbootfeatures: {include}/springbootfeatures
:include-productionreadyfeatures: {include}/productionreadyfeatures
:include-howto: {include}/howto
:spring-boot-code: https://github.com/{github-repo}/tree/{github-tag}
:spring-boot-api: https://docs.spring.io/spring-boot/docs/{spring-boot-version}/api
:spring-boot-docs: https://docs.spring.io/spring-boot/docs/{spring-boot-version}/reference
......@@ -38,7 +34,6 @@
:spring-boot-gradle-plugin-docs: https://docs.spring.io/spring-boot/docs/{spring-boot-version}/gradle-plugin/reference/htmlsingle/
:spring-boot-gradle-plugin-pdfdocs: https://docs.spring.io/spring-boot/docs/{spring-boot-version}/gradle-plugin/reference/pdf/spring-boot-gradle-plugin-reference.pdf
:spring-boot-gradle-plugin-api: https://docs.spring.io/spring-boot/docs/{spring-boot-version}/gradle-plugin/api/
:spring-boot-module-code: {spring-boot-code}/spring-boot-project/spring-boot/src/main/java/org/springframework/boot
:spring-boot-module-api: {spring-boot-api}/org/springframework/boot
:spring-boot-autoconfigure-module-code: {spring-boot-code}/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure
......@@ -55,7 +50,6 @@
:spring-boot-test-module-api: {spring-boot-api}/org/springframework/boot/test
:spring-boot-test-autoconfigure-module-code: {spring-boot-code}/spring-boot-project/spring-boot-test-autoconfigure/src/main/java/org/springframework/boot/test/autoconfigure
:spring-boot-test-autoconfigure-module-api: {spring-boot-api}/org/springframework/boot/test/autoconfigure
:spring-amqp-api: https://docs.spring.io/spring-amqp/docs/{spring-amqp-version}/api/org/springframework/amqp
:spring-batch: https://spring.io/projects/spring-batch
:spring-batch-api: https://docs.spring.io/spring-batch/docs/{spring-batch-version}/api/org/springframework/batch
......@@ -94,7 +88,6 @@
:spring-security-oauth2-docs: https://projects.spring.io/spring-security-oauth/docs/oauth2.html
:spring-session: https://spring.io/projects/spring-session
:spring-webservices-docs: https://docs.spring.io/spring-ws/docs/{spring-webservices-version}/reference/
:ant-docs: https://ant.apache.org/manual
:dependency-management-plugin-code: https://github.com/spring-gradle-plugins/dependency-management-plugin
:gradle-docs: https://docs.gradle.org/current/userguide
......
[appendix]
[[appendix.auto-configuration-classes]]
[[auto-configuration-classes]]
= Auto-configuration Classes
include::attributes.adoc[]
This appendix contains details of all of the auto-configuration classes provided by Spring Boot, with links to documentation and source code.
Remember to also look at the conditions report in your application for more details of which features are switched on.
(To do so, start the app with `--debug` or `-Ddebug` or, in an Actuator application, use the `conditions` endpoint).
[[appendix.auto-configuration-classes.core]]
== spring-boot-autoconfigure
The following auto-configuration classes are from the `spring-boot-autoconfigure` module:
include::auto-configuration-classes/spring-boot-autoconfigure.adoc[]
[[appendix.auto-configuration-classes.actuator]]
== spring-boot-actuator-autoconfigure
The following auto-configuration classes are from the `spring-boot-actuator-autoconfigure` module:
include::auto-configuration-classes/core.adoc[]
include::auto-configuration-classes/spring-boot-actuator-autoconfigure.adoc[]
include::auto-configuration-classes/actuator.adoc[]
[[auto-configuration-classes.actuator]]
== spring-boot-actuator-autoconfigure
The following auto-configuration classes are from the `spring-boot-actuator-autoconfigure` module:
include::documented-auto-configuration-classes/spring-boot-actuator-autoconfigure.adoc[]
[[auto-configuration-classes.core]]
== spring-boot-autoconfigure
The following auto-configuration classes are from the `spring-boot-autoconfigure` module:
include::documented-auto-configuration-classes/spring-boot-autoconfigure.adoc[]
......@@ -2,244 +2,21 @@
= Build Tool Plugins
include::attributes.adoc[]
Spring Boot provides build tool plugins for Maven and Gradle.
The plugins offer a variety of features, including the packaging of executable jars.
This section provides more details on both plugins as well as some help should you need to extend an unsupported build system.
If you are just getting started, you might want to read "`<<using.adoc#using.build-systems>>`" from the "`<<using.adoc#using>>`" section first.
[[build-tool-plugins.maven]]
== Spring Boot Maven Plugin
The Spring Boot Maven Plugin provides Spring Boot support in Maven, letting you package executable jar or war archives and run an application "`in-place`".
To use it, you must use Maven 3.2 (or later).
Please refer to the plugin's documentation to learn more:
* Reference ({spring-boot-maven-plugin-docs}[HTML] and {spring-boot-maven-plugin-pdfdocs}[PDF])
* {spring-boot-maven-plugin-api}[API]
[[build-tool-plugins.gradle]]
== Spring Boot Gradle Plugin
The Spring Boot Gradle Plugin provides Spring Boot support in Gradle, letting you package executable jar or war archives, run Spring Boot applications, and use the dependency management provided by `spring-boot-dependencies`.
It requires Gradle 6.8 or 7.x.
Please refer to the plugin's documentation to learn more:
* Reference ({spring-boot-gradle-plugin-docs}[HTML] and {spring-boot-gradle-plugin-pdfdocs}[PDF])
* {spring-boot-gradle-plugin-api}[API]
[[build-tool-plugins.antlib]]
== Spring Boot AntLib Module
The Spring Boot AntLib module provides basic Spring Boot support for Apache Ant.
You can use the module to create executable jars.
To use the module, you need to declare an additional `spring-boot` namespace in your `build.xml`, as shown in the following example:
[source,xml,indent=0]
----
<project xmlns:ivy="antlib:org.apache.ivy.ant"
xmlns:spring-boot="antlib:org.springframework.boot.ant"
name="myapp" default="build">
...
</project>
----
You need to remember to start Ant using the `-lib` option, as shown in the following example:
[indent=0,subs="verbatim,quotes,attributes"]
----
$ ant -lib <directory containing spring-boot-antlib-{spring-boot-version}.jar>
----
TIP: The "`Using Spring Boot`" section includes a more complete example of <<using.adoc#using.build-systems.ant, using Apache Ant with `spring-boot-antlib`>>.
[[build-tool-plugins.antlib.tasks]]
=== Spring Boot Ant Tasks
Once the `spring-boot-antlib` namespace has been declared, the following additional tasks are available:
* <<build-tool-plugins.antlib.tasks.exejar>>
* <<build-tool-plugins.antlib.findmainclass>>
[[build-tool-plugins.antlib.tasks.exejar]]
==== Using the "`exejar`" Task
You can use the `exejar` task to create a Spring Boot executable jar.
The following attributes are supported by the task:
[cols="1,2,2"]
|====
| Attribute | Description | Required
| `destfile`
| The destination jar file to create
| Yes
| `classes`
| The root directory of Java class files
| Yes
| `start-class`
| The main application class to run
| No _(the default is the first class found that declares a `main` method)_
|====
The following nested elements can be used with the task:
[cols="1,4"]
|====
| Element | Description
| `resources`
| One or more {ant-docs}/Types/resources.html#collection[Resource Collections] describing a set of {ant-docs}/Types/resources.html[Resources] that should be added to the content of the created +jar+ file.
| `lib`
| One or more {ant-docs}/Types/resources.html#collection[Resource Collections] that should be added to the set of jar libraries that make up the runtime dependency classpath of the application.
|====
[[build-tool-plugins.antlib.tasks.examples]]
==== Examples
This section shows two examples of Ant tasks.
.Specify +start-class+
[source,xml,indent=0]
----
<spring-boot:exejar destfile="target/my-application.jar"
classes="target/classes" start-class="com.example.MyApplication">
<resources>
<fileset dir="src/main/resources" />
</resources>
<lib>
<fileset dir="lib" />
</lib>
</spring-boot:exejar>
----
.Detect +start-class+
[source,xml,indent=0]
----
<exejar destfile="target/my-application.jar" classes="target/classes">
<lib>
<fileset dir="lib" />
</lib>
</exejar>
----
[[build-tool-plugins.antlib.findmainclass]]
=== Using the "`findmainclass`" Task
The `findmainclass` task is used internally by `exejar` to locate a class declaring a `main`.
If necessary, you can also use this task directly in your build.
The following attributes are supported:
[cols="1,2,2"]
|====
| Attribute | Description | Required
| `classesroot`
| The root directory of Java class files
| Yes _(unless `mainclass` is specified)_
| `mainclass`
| Can be used to short-circuit the `main` class search
| No
| `property`
| The Ant property that should be set with the result
| No _(result will be logged if unspecified)_
|====
[[build-tool-plugins.antlib.findmainclass.examples]]
==== Examples
This section contains three examples of using `findmainclass`.
.Find and log
[source,xml,indent=0]
----
<findmainclass classesroot="target/classes" />
----
.Find and set
[source,xml,indent=0]
----
<findmainclass classesroot="target/classes" property="main-class" />
----
.Override and set
[source,xml,indent=0]
----
<findmainclass mainclass="com.example.MainClass" property="main-class" />
----
[[build-tool-plugins.other-build-systems]]
== Supporting Other Build Systems
If you want to use a build tool other than Maven, Gradle, or Ant, you likely need to develop your own plugin.
Executable jars need to follow a specific format and certain entries need to be written in an uncompressed form (see the "`<<executable-jar.adoc#appendix.executable-jar, executable jar format>>`" section in the appendix for details).
The Spring Boot Maven and Gradle plugins both make use of `spring-boot-loader-tools` to actually generate jars.
If you need to, you may use this library directly.
[[build-tool-plugins.other-build-systems.repackaging-archives]]
=== Repackaging Archives
To repackage an existing archive so that it becomes a self-contained executable archive, use `org.springframework.boot.loader.tools.Repackager`.
The `Repackager` class takes a single constructor argument that refers to an existing jar or war archive.
Use one of the two available `repackage()` methods to either replace the original file or write to a new destination.
Various settings can also be configured on the repackager before it is run.
[[build-tool-plugins.other-build-systems.nested-libraries]]
=== Nested Libraries
When repackaging an archive, you can include references to dependency files by using the `org.springframework.boot.loader.tools.Libraries` interface.
We do not provide any concrete implementations of `Libraries` here as they are usually build-system-specific.
If your archive already includes libraries, you can use `Libraries.NONE`.
[[build-tool-plugins.other-build-systems.finding-main-class]]
=== Finding a Main Class
If you do not use `Repackager.setMainClass()` to specify a main class, the repackager uses https://asm.ow2.io/[ASM] to read class files and tries to find a suitable class with a `public static void main(String[] args)` method.
An exception is thrown if more than one candidate is found.
If you are just getting started, you might want to read "`<<using#using.build-systems>>`" from the "`<<using#using>>`" section first.
[[build-tool-plugins.other-build-systems.example-repackage-implementation]]
=== Example Repackage Implementation
The following example shows a typical repackage implementation:
[source,java,pending-extract=true,indent=0]
----
Repackager repackager = new Repackager(sourceJarFile);
repackager.setBackupSource(false);
repackager.repackage(new Libraries() {
@Override
public void doWithLibraries(LibraryCallback callback) throws IOException {
// Build system specific implementation, callback for each dependency
// callback.library(new Library(nestedFile, LibraryScope.COMPILE));
}
});
----
include::build-tool-plugins/maven.adoc[]
include::build-tool-plugins/gradle.adoc[]
include::build-tool-plugins/antlib.adoc[]
[[build-tool-plugins.whats-next]]
== What to Read Next
If you are interested in how the build tool plugins work, you can look at the {spring-boot-code}/spring-boot-project/spring-boot-tools[`spring-boot-tools`] module on GitHub.
More technical details of the executable jar format are covered in <<appendix-executable-jar-format#appendix.executable-jar,the appendix>>.
include::build-tool-plugins/other-build-systems.adoc[]
If you have specific build-related questions, you can check out the "`<<howto.adoc#howto, how-to>>`" guides.
include::build-tool-plugins/whats-next.adoc[]
[[build-tool-plugins.antlib]]
== Spring Boot AntLib Module
The Spring Boot AntLib module provides basic Spring Boot support for Apache Ant.
You can use the module to create executable jars.
To use the module, you need to declare an additional `spring-boot` namespace in your `build.xml`, as shown in the following example:
[source,xml,indent=0]
----
<project xmlns:ivy="antlib:org.apache.ivy.ant"
xmlns:spring-boot="antlib:org.springframework.boot.ant"
name="myapp" default="build">
...
</project>
----
You need to remember to start Ant using the `-lib` option, as shown in the following example:
[indent=0,subs="verbatim,quotes,attributes"]
----
$ ant -lib <directory containing spring-boot-antlib-{spring-boot-version}.jar>
----
TIP: The "`Using Spring Boot`" section includes a more complete example of <<using#using.build-systems.ant, using Apache Ant with `spring-boot-antlib`>>.
[[build-tool-plugins.antlib.tasks]]
=== Spring Boot Ant Tasks
Once the `spring-boot-antlib` namespace has been declared, the following additional tasks are available:
* <<build-tool-plugins#build-tool-plugins.antlib.tasks.exejar>>
* <<build-tool-plugins#build-tool-plugins.antlib.findmainclass>>
[[build-tool-plugins.antlib.tasks.exejar]]
==== Using the "`exejar`" Task
You can use the `exejar` task to create a Spring Boot executable jar.
The following attributes are supported by the task:
[cols="1,2,2"]
|====
| Attribute | Description | Required
| `destfile`
| The destination jar file to create
| Yes
| `classes`
| The root directory of Java class files
| Yes
| `start-class`
| The main application class to run
| No _(the default is the first class found that declares a `main` method)_
|====
The following nested elements can be used with the task:
[cols="1,4"]
|====
| Element | Description
| `resources`
| One or more {ant-docs}/Types/resources.html#collection[Resource Collections] describing a set of {ant-docs}/Types/resources.html[Resources] that should be added to the content of the created +jar+ file.
| `lib`
| One or more {ant-docs}/Types/resources.html#collection[Resource Collections] that should be added to the set of jar libraries that make up the runtime dependency classpath of the application.
|====
[[build-tool-plugins.antlib.tasks.examples]]
==== Examples
This section shows two examples of Ant tasks.
.Specify +start-class+
[source,xml,indent=0]
----
<spring-boot:exejar destfile="target/my-application.jar"
classes="target/classes" start-class="com.example.MyApplication">
<resources>
<fileset dir="src/main/resources" />
</resources>
<lib>
<fileset dir="lib" />
</lib>
</spring-boot:exejar>
----
.Detect +start-class+
[source,xml,indent=0]
----
<exejar destfile="target/my-application.jar" classes="target/classes">
<lib>
<fileset dir="lib" />
</lib>
</exejar>
----
[[build-tool-plugins.antlib.findmainclass]]
=== Using the "`findmainclass`" Task
The `findmainclass` task is used internally by `exejar` to locate a class declaring a `main`.
If necessary, you can also use this task directly in your build.
The following attributes are supported:
[cols="1,2,2"]
|====
| Attribute | Description | Required
| `classesroot`
| The root directory of Java class files
| Yes _(unless `mainclass` is specified)_
| `mainclass`
| Can be used to short-circuit the `main` class search
| No
| `property`
| The Ant property that should be set with the result
| No _(result will be logged if unspecified)_
|====
[[build-tool-plugins.antlib.findmainclass.examples]]
==== Examples
This section contains three examples of using `findmainclass`.
.Find and log
[source,xml,indent=0]
----
<findmainclass classesroot="target/classes" />
----
.Find and set
[source,xml,indent=0]
----
<findmainclass classesroot="target/classes" property="main-class" />
----
.Override and set
[source,xml,indent=0]
----
<findmainclass mainclass="com.example.MainClass" property="main-class" />
----
[[build-tool-plugins.gradle]]
== Spring Boot Gradle Plugin
The Spring Boot Gradle Plugin provides Spring Boot support in Gradle, letting you package executable jar or war archives, run Spring Boot applications, and use the dependency management provided by `spring-boot-dependencies`.
It requires Gradle 6.8 or 7.x.
Please refer to the plugin's documentation to learn more:
* Reference ({spring-boot-gradle-plugin-docs}[HTML] and {spring-boot-gradle-plugin-pdfdocs}[PDF])
* {spring-boot-gradle-plugin-api}[API]
[[build-tool-plugins.maven]]
== Spring Boot Maven Plugin
The Spring Boot Maven Plugin provides Spring Boot support in Maven, letting you package executable jar or war archives and run an application "`in-place`".
To use it, you must use Maven 3.2 (or later).
Please refer to the plugin's documentation to learn more:
* Reference ({spring-boot-maven-plugin-docs}[HTML] and {spring-boot-maven-plugin-pdfdocs}[PDF])
* {spring-boot-maven-plugin-api}[API]
[[build-tool-plugins.other-build-systems]]
== Supporting Other Build Systems
If you want to use a build tool other than Maven, Gradle, or Ant, you likely need to develop your own plugin.
Executable jars need to follow a specific format and certain entries need to be written in an uncompressed form (see the "`<<executable-jar#executable-jar, executable jar format>>`" section in the appendix for details).
The Spring Boot Maven and Gradle plugins both make use of `spring-boot-loader-tools` to actually generate jars.
If you need to, you may use this library directly.
[[build-tool-plugins.other-build-systems.repackaging-archives]]
=== Repackaging Archives
To repackage an existing archive so that it becomes a self-contained executable archive, use `org.springframework.boot.loader.tools.Repackager`.
The `Repackager` class takes a single constructor argument that refers to an existing jar or war archive.
Use one of the two available `repackage()` methods to either replace the original file or write to a new destination.
Various settings can also be configured on the repackager before it is run.
[[build-tool-plugins.other-build-systems.nested-libraries]]
=== Nested Libraries
When repackaging an archive, you can include references to dependency files by using the `org.springframework.boot.loader.tools.Libraries` interface.
We do not provide any concrete implementations of `Libraries` here as they are usually build-system-specific.
If your archive already includes libraries, you can use `Libraries.NONE`.
[[build-tool-plugins.other-build-systems.finding-main-class]]
=== Finding a Main Class
If you do not use `Repackager.setMainClass()` to specify a main class, the repackager uses https://asm.ow2.io/[ASM] to read class files and tries to find a suitable class with a `public static void main(String[] args)` method.
An exception is thrown if more than one candidate is found.
[[build-tool-plugins.other-build-systems.example-repackage-implementation]]
=== Example Repackage Implementation
The following example shows a typical repackage implementation:
[source,java,pending-extract=true,indent=0]
----
Repackager repackager = new Repackager(sourceJarFile);
repackager.setBackupSource(false);
repackager.repackage(new Libraries() {
@Override
public void doWithLibraries(LibraryCallback callback) throws IOException {
// Build system specific implementation, callback for each dependency
// callback.library(new Library(nestedFile, LibraryScope.COMPILE));
}
});
----
[[build-tool-plugins.whats-next]]
== What to Read Next
If you are interested in how the build tool plugins work, you can look at the {spring-boot-code}/spring-boot-project/spring-boot-tools[`spring-boot-tools`] module on GitHub.
More technical details of the executable jar format are covered in <<executable-jar#executable-jar,the appendix>>.
If you have specific build-related questions, you can check out the "`<<howto#howto, how-to>>`" guides.
[[cli.groovy-beans-dsl]]
== Developing Applications with the Groovy Beans DSL
Spring Framework 4.0 has native support for a `beans{}` "`DSL`" (borrowed from https://grails.org/[Grails]), and you can embed bean definitions in your Groovy application scripts by using the same format.
This is sometimes a good way to include external features like middleware declarations, as shown in the following example:
[source,groovy,indent=0]
----
@Configuration(proxyBeanMethods = false)
class Application implements CommandLineRunner {
@Autowired
SharedService service
@Override
void run(String... args) {
println service.message
}
}
import my.company.SharedService
beans {
service(SharedService) {
message = "Hello World"
}
}
----
You can mix class declarations with `beans{}` in the same file as long as they stay at the top level, or, if you prefer, you can put the beans DSL in a separate file.
[[cli.installation]]
== Installing the CLI
The Spring Boot CLI (Command-Line Interface) can be installed manually by using SDKMAN! (the SDK Manager) or by using Homebrew or MacPorts if you are an OSX user.
See _<<getting-started#getting-started.installing.cli>>_ in the "`Getting started`" section for comprehensive installation instructions.
[[cli.maven-setting]]
== Configuring the CLI with settings.xml
The Spring Boot CLI uses Aether, Maven's dependency resolution engine, to resolve dependencies.
The CLI makes use of the Maven configuration found in `~/.m2/settings.xml` to configure Aether.
The following configuration settings are honored by the CLI:
* Offline
* Mirrors
* Servers
* Proxies
* Profiles
** Activation
** Repositories
* Active profiles
See https://maven.apache.org/settings.html[Maven's settings documentation] for further information.
[[cli.whats-next]]
== What to Read Next
There are some {spring-boot-code}/spring-boot-project/spring-boot-cli/samples[sample groovy scripts] available from the GitHub repository that you can use to try out the Spring Boot CLI.
There is also extensive Javadoc throughout the {spring-boot-cli-module-code}[source code].
If you find that you reach the limit of the CLI tool, you probably want to look at converting your application to a full Gradle or Maven built "`Groovy project`".
The next section covers Spring Boot's "<<build-tool-plugins#build-tool-plugins, Build tool plugins>>", which you can use with Gradle or Maven.
:numbered!:
[appendix]
[[appendix.common-application-properties]]
= Common Application properties
include::attributes.adoc[]
Various properties can be specified inside your `application.properties` file, inside your `application.yml` file, or as command line switches.
This appendix provides a list of common Spring Boot properties and references to the underlying classes that consume them.
TIP: Spring Boot provides various conversion mechanism with advanced value formatting, make sure to review <<features.adoc#features.external-config.typesafe-configuration-properties.conversion, the properties conversion section>>.
NOTE: Property contributions can come from additional jar files on your classpath, so you should not consider this an exhaustive list.
Also, you can define your own properties.
[[appendix.common-application-properties.core]]
== Core Properties [[core-properties]]
include::config-docs/core.adoc[]
[[appendix.common-application-properties.cache]]
== Cache Properties [[cache-properties]]
include::config-docs/cache.adoc[]
[[appendix.common-application-properties.mail]]
== Mail Properties [[mail-properties]]
include::config-docs/mail.adoc[]
[[appendix.common-application-properties.json]]
== JSON Properties [[json-properties]]
include::config-docs/json.adoc[]
[[appendix.common-application-properties.data]]
== Data Properties [[data-properties]]
include::config-docs/data.adoc[]
[[appendix.common-application-properties.transaction]]
== Transaction Properties [[transaction-properties]]
include::config-docs/transaction.adoc[]
[[appendix.common-application-properties.data-migration]]
== Data Migration Properties [[data-migration-properties]]
include::config-docs/data-migration.adoc[]
[[appendix.common-application-properties.integration]]
== Integration Properties [[integration-properties]]
include::config-docs/integration.adoc[]
[[appendix.common-application-properties.web]]
== Web Properties [[web-properties]]
include::config-docs/web.adoc[]
[[appendix.common-application-properties.templating]]
== Templating Properties [[templating-properties]]
include::config-docs/templating.adoc[]
[[appendix.common-application-properties.server]]
== Server Properties [[server-properties]]
include::config-docs/server.adoc[]
[[appendix.common-application-properties.security]]
== Security Properties [[security-properties]]
include::config-docs/security.adoc[]
[[appendix.common-application-properties.rsocket]]
== RSocket Properties [[rsocket-properties]]
include::config-docs/rsocket.adoc[]
[[appendix.common-application-properties.actuator]]
== Actuator Properties [[actuator-properties]]
include::config-docs/actuator.adoc[]
[[appendix.common-application-properties.devtools]]
== Devtools Properties [[devtools-properties]]
include::config-docs/devtools.adoc[]
[[appendix.common-application-properties.testing]]
== Testing Properties [[testing-properties]]
include::config-docs/testing.adoc[]
[[configuration-metadata.annotation-processor]]
== Generating Your Own Metadata by Using the Annotation Processor
You can easily generate your own configuration metadata file from items annotated with `@ConfigurationProperties` by using the `spring-boot-configuration-processor` jar.
The jar includes a Java annotation processor which is invoked as your project is compiled.
[[configuration-metadata.annotation-processor.configuring]]
=== Configuring the Annotation Processor
To use the processor, include a dependency on `spring-boot-configuration-processor`.
With Maven the dependency should be declared as optional, as shown in the following example:
[source,xml,indent=0,subs="verbatim,quotes,attributes"]
----
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-configuration-processor</artifactId>
<optional>true</optional>
</dependency>
----
With Gradle, the dependency should be declared in the `annotationProcessor` configuration, as shown in the following example:
[source,groovy,indent=0,subs="verbatim,quotes,attributes"]
----
dependencies {
annotationProcessor "org.springframework.boot:spring-boot-configuration-processor"
}
----
If you are using an `additional-spring-configuration-metadata.json` file, the `compileJava` task should be configured to depend on the `processResources` task, as shown in the following example:
[source,groovy,indent=0,subs="verbatim,quotes,attributes"]
----
compileJava.inputs.files(processResources)
----
This dependency ensures that the additional metadata is available when the annotation processor runs during compilation.
[NOTE]
====
If you are using AspectJ in your project, you need to make sure that the annotation processor runs only once.
There are several ways to do this.
With Maven, you can configure the `maven-apt-plugin` explicitly and add the dependency to the annotation processor only there.
You could also let the AspectJ plugin run all the processing and disable annotation processing in the `maven-compiler-plugin` configuration, as follows:
[source,xml,indent=0,subs="verbatim,quotes,attributes"]
----
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<proc>none</proc>
</configuration>
</plugin>
----
====
[[configuration-metadata.annotation-processor.automatic-metadata-generation]]
=== Automatic Metadata Generation
The processor picks up both classes and methods that are annotated with `@ConfigurationProperties`.
If the class is also annotated with `@ConstructorBinding`, a single constructor is expected and one property is created per constructor parameter.
Otherwise, properties are discovered through the presence of standard getters and setters with special handling for collection and map types (that is detected even if only a getter is present).
The annotation processor also supports the use of the `@Data`, `@Getter`, and `@Setter` lombok annotations.
Consider the following example:
[source,java,pending-extract=true,indent=0,subs="verbatim,attributes"]
----
@ConfigurationProperties(prefix="server")
public class ServerProperties {
/**
* Name of the server.
*/
private String name;
/**
* IP address to listen to.
*/
private String ip = "127.0.0.1";
/**
* Port to listener to.
*/
private int port = 9797;
// ... getter and setters
}
----
This exposes three properties where `server.name` has no default and `server.ip` and `server.port` defaults to `"127.0.0.1"` and `9797` respectively.
The Javadoc on fields is used to populate the `description` attribute. For instance, the description of `server.ip` is "IP address to listen to.".
NOTE: You should only use plain text with `@ConfigurationProperties` field Javadoc, since they are not processed before being added to the JSON.
The annotation processor applies a number of heuristics to extract the default value from the source model.
Default values have to be provided statically. In particular, do not refer to a constant defined in another class.
Also, the annotation processor cannot auto-detect default values for ``Enum``s and ``Collections``s.
For cases where the default value could not be detected, <<configuration-metadata#configuration-metadata.annotation-processor.adding-additional-metadata,manual metadata>> should be provided.
Consider the following example:
[source,java,pending-extract=true,indent=0,subs="verbatim,quotes,attributes"]
----
@ConfigurationProperties(prefix = "acme.messaging")
public class MessagingProperties {
private List<String> addresses = new ArrayList<>(Arrays.asList("a", "b"));
private ContainerType containerType = ContainerType.SIMPLE;
// ... getter and setters
public enum ContainerType {
SIMPLE,
DIRECT
}
}
----
In order to document default values for properties in the class above, you could add the following content to <<configuration-metadata#configuration-metadata.annotation-processor.adding-additional-metadata,the manual metadata of the module>>:
[source,json,indent=0]
----
{"properties": [
{
"name": "acme.messaging.addresses",
"defaultValue": ["a", "b"]
},
{
"name": "acme.messaging.container-type",
"defaultValue": "simple"
}
]}
----
NOTE: Only the `name` of the property is required to document additional metadata for existing properties.
[[configuration-metadata.annotation-processor.automatic-metadata-generation.nested-properties]]
==== Nested Properties
The annotation processor automatically considers inner classes as nested properties.
Rather than documenting the `ip` and `port` at the root of the namespace, we could create a sub-namespace for it.
Consider the updated example:
[source,java,pending-extract=true,indent=0,subs="verbatim,quotes,attributes"]
----
@ConfigurationProperties(prefix="server")
public class ServerProperties {
private String name;
private Host host;
// ... getter and setters
public static class Host {
private String ip;
private int port;
// ... getter and setters
}
}
----
The preceding example produces metadata information for `server.name`, `server.host.ip`, and `server.host.port` properties.
You can use the `@NestedConfigurationProperty` annotation on a field to indicate that a regular (non-inner) class should be treated as if it were nested.
TIP: This has no effect on collections and maps, as those types are automatically identified, and a single metadata property is generated for each of them.
[[configuration-metadata.annotation-processor.adding-additional-metadata]]
=== Adding Additional Metadata
Spring Boot's configuration file handling is quite flexible, and it is often the case that properties may exist that are not bound to a `@ConfigurationProperties` bean.
You may also need to tune some attributes of an existing key.
To support such cases and let you provide custom "hints", the annotation processor automatically merges items from `META-INF/additional-spring-configuration-metadata.json` into the main metadata file.
If you refer to a property that has been detected automatically, the description, default value, and deprecation information are overridden, if specified.
If the manual property declaration is not identified in the current module, it is added as a new property.
The format of the `additional-spring-configuration-metadata.json` file is exactly the same as the regular `spring-configuration-metadata.json`.
The additional properties file is optional.
If you do not have any additional properties, do not add the file.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment