From 2595258494fe58108568ac2b88573af3f577577c Mon Sep 17 00:00:00 2001
From: Phillip Webb <pwebb@vmware.com>
Date: Tue, 6 Oct 2020 18:49:03 -0700
Subject: [PATCH] Provide both properties and YAML examples in docs

Update all configuration examples in the docs to YAML and make use of
the new `configblocks` spring-asciidoctor-extensions feature to
automatically create both "Properties" and "Yaml" versions.

Closes gh-23515
---
 .../spring-boot-docs/build.gradle             |    1 +
 .../src/docs/asciidoc/howto.adoc              |  296 +++--
 .../asciidoc/production-ready-features.adoc   |  575 +++++++---
 .../docs/asciidoc/spring-boot-features.adoc   | 1021 +++++++++++------
 .../src/docs/asciidoc/using-spring-boot.adoc  |   49 +-
 5 files changed, 1287 insertions(+), 655 deletions(-)

diff --git a/spring-boot-project/spring-boot-docs/build.gradle b/spring-boot-project/spring-boot-docs/build.gradle
index b98212df48..bf2861e22a 100644
--- a/spring-boot-project/spring-boot-docs/build.gradle
+++ b/spring-boot-project/spring-boot-docs/build.gradle
@@ -46,6 +46,7 @@ plugins.withType(EclipsePlugin) {
 dependencies {
 	actuatorApiDocumentation(project(path: ":spring-boot-project:spring-boot-actuator-autoconfigure", configuration: "documentation"))
 
+	asciidoctorExtensions("io.spring.asciidoctor:spring-asciidoctor-extensions-block-switch")
 	asciidoctorExtensions("io.spring.asciidoctor:spring-asciidoctor-extensions-spring-boot")
 	asciidoctorExtensions(project(path: ":spring-boot-project:spring-boot-actuator-autoconfigure"))
 	asciidoctorExtensions(project(path: ":spring-boot-project:spring-boot-autoconfigure"))
diff --git a/spring-boot-project/spring-boot-docs/src/docs/asciidoc/howto.adoc b/spring-boot-project/spring-boot-docs/src/docs/asciidoc/howto.adoc
index ba5e739b82..2a4f621a9b 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/asciidoc/howto.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/asciidoc/howto.adoc
@@ -85,7 +85,7 @@ See "`<<spring-boot-features.adoc#boot-features-application-events-and-listeners
 It is also possible to customize the `Environment` before the application context is refreshed by using `EnvironmentPostProcessor`.
 Each implementation should be registered in `META-INF/spring.factories`, as shown in the following example:
 
-[source,properties,indent=0]
+[indent=0]
 ----
 	org.springframework.boot.env.EnvironmentPostProcessor=com.example.YourEnvironmentPostProcessor
 ----
@@ -145,10 +145,12 @@ This is possible in both Maven and Gradle.
 You can automatically expand properties from the Maven project by using resource filtering.
 If you use the `spring-boot-starter-parent`, you can then refer to your Maven '`project properties`' with `@..@` placeholders, as shown in the following example:
 
-[source,properties,indent=0]
+[source,yaml,indent=0,configblocks]
 ----
-	app.encoding=@project.build.sourceEncoding@
-	app.java.version=@java.version@
+	app:
+	  encoding: "@project.build.sourceEncoding@"
+	  java:
+	    version: "@java.version@"
 ----
 
 NOTE: Only production configuration is filtered that way (in other words, no filtering is applied on `src/test/resources`).
@@ -205,10 +207,11 @@ You can automatically expand properties from the Gradle project by configuring t
 
 You can then refer to your Gradle project's properties by using placeholders, as shown in the following example:
 
-[source,properties,indent=0]
+[source,yaml,indent=0,configblocks]
 ----
-	app.name=${name}
-	app.description=${description}
+	app:
+	  name: "${name}"
+	  description: "${description}"
 ----
 
 NOTE: Gradle's `expand` method uses Groovy's `SimpleTemplateEngine`, which transforms `${..}` tokens.
@@ -223,10 +226,12 @@ A `SpringApplication` has bean properties (mainly setters), so you can use its J
 Alternatively, you can externalize the configuration by setting properties in `+spring.main.*+`.
 For example, in `application.properties`, you might have the following settings:
 
-[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
+[source,yaml,indent=0,subs="verbatim,quotes,attributes",configprops,configblocks]
 ----
-	spring.main.web-application-type=none
-	spring.main.banner-mode=off
+	spring:
+	  main:
+	    web-application-type: "none"
+	    banner-mode: "off"
 ----
 
 Then the Spring Boot banner is not printed on startup, and the application is not starting an embedded web server.
@@ -244,10 +249,12 @@ Consider the following application:
 
 Now consider the following configuration:
 
-[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
+[source,yaml,indent=0,subs="verbatim,quotes,attributes",configprops,configblocks]
 ----
-	spring.main.sources=com.acme.Config,com.acme.ExtraConfig
-	spring.main.banner-mode=console
+	spring:
+	  main:
+	    sources: "com.acme.Config,com.acme.ExtraConfig"
+	    banner-mode: "console"
 ----
 
 The actual application _now_ shows the banner (as overridden by configuration) and uses three sources for the `ApplicationContext` (in the following order): `demo.MyApp`, `com.acme.Config`, and `com.acme.ExtraConfig`.
@@ -278,9 +285,10 @@ See {spring-boot-module-code}/context/config/ConfigFileApplicationListener.java[
 Some people like to use (for example) `--port=9000` instead of `--server.port=9000` to set configuration properties on the command line.
 You can enable this behavior by using placeholders in `application.properties`, as shown in the following example:
 
-[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
+[source,yaml,indent=0,subs="verbatim,quotes,attributes",configprops,configblocks]
 ----
-	server.port=${port:8080}
+	server:
+	  port: "${port:8080}"
 ----
 
 TIP: If you inherit from the `spring-boot-starter-parent` POM, the default filter token of the `maven-resources-plugins` has been changed from `+${*}+` to `@` (that is, `@maven.token@` instead of `${maven.token}`) to prevent conflicts with Spring-style placeholders.
@@ -298,13 +306,13 @@ YAML is a superset of JSON and, as such, is a convenient syntax for storing exte
 [source,yaml,indent=0,subs="verbatim,quotes,attributes"]
 ----
 	spring:
-		application:
-			name: cruncher
-		datasource:
-			driverClassName: com.mysql.jdbc.Driver
-			url: jdbc:mysql://localhost/test
+	  application:
+	    name: "cruncher"
+	  datasource:
+	    driver-class-name: "com.mysql.jdbc.Driver"
+	    url: "jdbc:mysql://localhost/test"
 	server:
-		port: 9000
+	  port: 9000
 ----
 
 Create a file called `application.yml` and put it in the root of your classpath.
@@ -337,9 +345,11 @@ Also, you can launch your application with a `-D` argument (remember to put it b
 
 In Spring Boot, you can also set the active profile in `application.properties`, as shown in the following example:
 
-[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
+[source,yaml,indent=0,subs="verbatim,quotes,attributes",configprops,configblocks]
 ----
-	spring.profiles.active=production
+	spring:
+	  profiles:
+	    active: "production"
 ----
 
 A value set this way is replaced by the System property or environment variable setting but not by the `SpringApplicationBuilder.profiles()` method.
@@ -356,15 +366,24 @@ Spring Boot supports multi-document YAML and Properties files (see <<spring-boot
 If a document contains a `spring.config.activate.on-profile` key, then the profiles value (a comma-separated list of profiles or a profile expression) is fed into the Spring `Environment.acceptsProfiles()` method.
 If the profile expression matches then that document is included in the final merge (otherwise, it is not), as shown in the following example:
 
-[source,yaml,indent=0,subs="verbatim,quotes,attributes"]
+[source,yaml,indent=0,subs="verbatim,quotes,attributes",configprops,configblocks]
 ----
-	server.port: 9000
+	server:
+	  port: 9000
 	---
-	spring.config.activate.on-profile: development
-	server.port: 9001
+	spring:
+	  config:
+	    activate:
+	      on-profile: "development"
+	server:
+	  port: 9001
 	---
-	spring.config.activate.on-profile: production
-	server.port: 0
+	spring:
+	  config:
+	    activate:
+	      on-profile: "production"
+	server:
+	  port: 0
 ----
 
 In the preceding example, the default port is 9000.
@@ -461,9 +480,11 @@ NOTE: `spring-boot-starter-reactor-netty` is required to use the `WebClient` cla
 If your classpath contains the necessary bits to start a web server, Spring Boot will automatically start it.
 To disable this behavior configure the `WebApplicationType` in your `application.properties`, as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.main.web-application-type=none
+	spring:
+	  main:
+	    web-application-type: "none"
 ----
 
 
@@ -520,9 +541,11 @@ Contrary to a test, application code callbacks are processed early (before the v
 HTTP response compression is supported by Jetty, Tomcat, and Undertow.
 It can be enabled in `application.properties`, as follows:
 
-[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
+[source,yaml,indent=0,subs="verbatim,quotes,attributes",configprops,configblocks]
 ----
-	server.compression.enabled=true
+	server:
+	  compression:
+	    enabled: true
 ----
 
 By default, responses must be at least 2048 bytes in length for compression to be performed.
@@ -548,12 +571,14 @@ You can configure this behavior by setting the configprop:server.compression.mim
 SSL can be configured declaratively by setting the various `+server.ssl.*+` properties, typically in `application.properties` or `application.yml`.
 The following example shows setting SSL properties in `application.properties`:
 
-[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
+[source,yaml,indent=0,subs="verbatim,quotes,attributes",configprops,configblocks]
 ----
-	server.port=8443
-	server.ssl.key-store=classpath:keystore.jks
-	server.ssl.key-store-password=secret
-	server.ssl.key-password=another-secret
+	server:
+	  port: 8443
+	  ssl:
+	    key-store: "classpath:keystore.jks"
+	    key-store-password: "secret"
+	    key-password: "another-secret"
 ----
 
 See {spring-boot-module-code}/web/server/Ssl.java[`Ssl`] for details of all of the supported properties.
@@ -742,11 +767,14 @@ Access logs can be configured for Tomcat, Undertow, and Jetty through their resp
 
 For instance, the following settings log access on Tomcat with a {tomcat-docs}/config/valve.html#Access_Logging[custom pattern].
 
-[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
+[source,yaml,indent=0,subs="verbatim,quotes,attributes",configprops,configblocks]
 ----
-	server.tomcat.basedir=my-tomcat
-	server.tomcat.accesslog.enabled=true
-	server.tomcat.accesslog.pattern=%t %a "%r" %s (%D ms)
+	server:
+	  tomcat:
+	    basedir: "my-tomcat"
+	    accesslog:
+	      enabled: true
+	      pattern: "%t %a %r %s (%D ms)"
 ----
 
 NOTE: The default location for logs is a `logs` directory relative to the Tomcat base directory.
@@ -755,10 +783,13 @@ In the preceding example, the logs are available in `my-tomcat/logs` relative to
 
 Access logging for Undertow can be configured in a similar fashion, as shown in the following example:
 
-[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
+[source,yaml,indent=0,subs="verbatim,quotes,attributes",configprops,configblocks]
 ----
-	server.undertow.accesslog.enabled=true
-	server.undertow.accesslog.pattern=%t %a "%r" %s (%D ms)
+	server:
+	  undertow:
+	    accesslog:
+	      enabled: true
+	      pattern: "%t %a %r %s (%D ms)"
 ----
 
 Logs are stored in a `logs` directory relative to the working directory of the application.
@@ -766,10 +797,13 @@ You can customize this location by setting the configprop:server.undertow.access
 
 Finally, access logging for Jetty can also be configured as follows:
 
-[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
+[source,yaml,indent=0,subs="verbatim,quotes,attributes",configprops,configblocks]
 ----
-	server.jetty.accesslog.enabled=true
-	server.jetty.accesslog.filename=/var/log/jetty-access.log
+	server:
+	  jetty:
+	    accesslog:
+	      enabled: true
+	      filename: "/var/log/jetty-access.log"
 ----
 
 By default, logs are redirected to `System.err`.
@@ -801,24 +835,27 @@ In all other instances, it defaults to `NONE`.
 ==== Customize Tomcat's Proxy Configuration
 If you use Tomcat, you can additionally configure the names of the headers used to carry "`forwarded`" information, as shown in the following example:
 
-[indent=0]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	server.tomcat.remoteip.remote-ip-header=x-your-remote-ip-header
-	server.tomcat.remoteip.protocol-header=x-your-protocol-header
+	server:
+	  tomcat:
+	    remoteip:
+	      remote-ip-header: "x-your-remote-ip-header"
+	      protocol-header: "x-your-protocol-header"
 ----
 
 Tomcat is also configured with a default regular expression that matches internal proxies that are to be trusted.
 By default, IP addresses in `10/8`, `192.168/16`, `169.254/16` and `127/8` are trusted.
 You can customize the valve's configuration by adding an entry to `application.properties`, as shown in the following example:
 
-[indent=0]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	server.tomcat.remoteip.internal-proxies=192\\.168\\.\\d{1,3}\\.\\d{1,3}
+	server:
+	  tomcat:
+	    remoteip:
+	      internal-proxies: "192\\.168\\.\\d{1,3}\\.\\d{1,3}"
 ----
 
-NOTE: The double backslashes are required only when you use a properties file for configuration.
-If you use YAML, single backslashes are sufficient, and a value equivalent to that shown in the preceding example would be `192\.168\.\d{1,3}\.\d{1,3}`.
-
 NOTE: You can trust all proxies by setting the `internal-proxies` to empty (but do not do so in production).
 
 You can take complete control of the configuration of Tomcat's `RemoteIpValve` by switching the automatic one off (to do so, set `server.forward-headers-strategy=NONE`) and adding a new valve instance in a `TomcatServletWebServerFactory` bean.
@@ -890,9 +927,12 @@ Embedded Tomcat's MBean registry is disabled by default.
 This minimizes Tomcat's memory footprint.
 If you want to use Tomcat's MBeans, for example so that they can be used to expose metrics via Micrometer, you must use the configprop:server.tomcat.mbeanregistry.enabled[] property to do so, as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-server.tomcat.mbeanregistry.enabled=true
+server:
+  tomcat:
+    mbeanregistry:
+      enabled: true
 ----
 
 
@@ -1110,9 +1150,12 @@ NOTE: It is recommended to use the container's built-in support for multipart up
 By default, all content is served from the root of your application (`/`).
 If you would rather map to a different path, you can configure one as follows:
 
-[source,properties,indent=0,subs="verbatim",configprops]
+[source,yaml,indent=0,subs="verbatim",configprops,configblocks]
 ----
-	spring.mvc.servlet.path=/acme
+	spring:
+	  mvc:
+	    servlet:
+	      path: "/acme"
 ----
 
 If you have additional servlets you can declare a `@Bean` of type `Servlet` or `ServletRegistrationBean` for each and Spring Boot will register them transparently to the container.
@@ -1299,13 +1342,15 @@ If Logback is available, it is the first choice.
 
 If the only change you need to make to logging is to set the levels of various loggers, you can do so in `application.properties` by using the "logging.level" prefix, as shown in the following example:
 
-[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
+[source,yaml,indent=0,subs="verbatim,quotes,attributes",configprops,configblocks]
 ----
-	logging.level.org.springframework.web=DEBUG
-	logging.level.org.hibernate=ERROR
+	logging:
+	  level:
+	    org.springframework.web: "debug"
+	    org.hibernate: "error"
 ----
 
-You can also set the location of a file to which to write the log (in addition to the console) by using "logging.file.name".
+You can also set the location of a file to which to write the log (in addition to the console) by using `logging.file.name`.
 
 To configure the more fine-grained settings of a logging system, you need to use the native configuration format supported by the `LoggingSystem` in question.
 By default, Spring Boot picks up the native configuration from its default location for the system (such as `classpath:logback.xml` for Logback), but you can set the location of the config file by using the configprop:logging.config[] property.
@@ -1382,11 +1427,13 @@ If you want to disable console logging and write output only to a file, you need
 	</configuration>
 ----
 
-You also need to add `logging.file.name` to your `application.properties`, as shown in the following example:
+You also need to add `logging.file.name` to your `application.properties` or `application.yaml`, as shown in the following example:
 
-[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
+[source,yaml,indent=0,subs="verbatim,quotes,attributes",configprops,configblocks]
 ----
-	logging.file.name=myapplication.log
+	logging:
+	  file:
+	    name: "myapplication.log"
 ----
 
 
@@ -1492,11 +1539,13 @@ The following example shows how to define a data source in a bean:
 
 The following example shows how to define a data source by setting properties:
 
-[source,properties,indent=0]
+[source,yaml,indent=0,configblocks]
 ----
-	app.datasource.url=jdbc:h2:mem:mydb
-	app.datasource.username=sa
-	app.datasource.pool-size=30
+	app:
+	  datasource:
+	    url: "jdbc:h2:mem:mydb"
+	    username: "sa"
+	    pool-size: 30
 ----
 
 Assuming that your `FancyDataSource` has regular JavaBean properties for the URL, the username, and the pool size, these settings are bound automatically before the `DataSource` is made available to other components.
@@ -1519,12 +1568,14 @@ Check the implementation that is going to be used at runtime for more details.
 
 The following example shows how to define a JDBC data source by setting properties:
 
-[source,properties,indent=0]
+[source,yaml,indent=0,configblocks]
 ----
-	app.datasource.url=jdbc:mysql://localhost/test
-	app.datasource.username=dbuser
-	app.datasource.password=dbpass
-	app.datasource.pool-size=30
+	app:
+	  datasource:
+	    url: "jdbc:mysql://localhost/test"
+	    username: "dbuser"
+	    password: "dbpass"
+	    pool-size: 30
 ----
 
 However, there is a catch.
@@ -1532,12 +1583,14 @@ Because the actual type of the connection pool is not exposed, no keys are gener
 Also, if you happen to have Hikari on the classpath, this basic setup does not work, because Hikari has no `url` property (but does have a `jdbcUrl` property).
 In that case, you must rewrite your configuration as follows:
 
-[source,properties,indent=0]
+[source,yaml,indent=0,configblocks]
 ----
-	app.datasource.jdbc-url=jdbc:mysql://localhost/test
-	app.datasource.username=dbuser
-	app.datasource.password=dbpass
-	app.datasource.maximum-pool-size=30
+	app:
+	  datasource:
+	    jdbc-url: "jdbc:mysql://localhost/test"
+	    username: "dbuser"
+	    password: "dbpass"
+	    pool-size: 30
 ----
 
 You can fix that by forcing the connection pool to use and return a dedicated implementation rather than `DataSource`.
@@ -1563,12 +1616,15 @@ include::{code-examples}/jdbc/ConfigurableDataSourceExample.java[tag=configurati
 This setup puts you _in sync_ with what Spring Boot does for you by default, except that a dedicated connection pool is chosen (in code) and its settings are exposed in the `app.datasource.configuration` sub namespace.
 Because `DataSourceProperties` is taking care of the `url`/`jdbcUrl` translation for you, you can configure it as follows:
 
-[source,properties,indent=0]
+[source,yaml,indent=0,configblocks]
 ----
-	app.datasource.url=jdbc:mysql://localhost/test
-	app.datasource.username=dbuser
-	app.datasource.password=dbpass
-	app.datasource.configuration.maximum-pool-size=30
+	app:
+	  datasource:
+	    url: "jdbc:mysql://localhost/test"
+	    username: "dbuser"
+	    password: "dbpass"
+	    configuration:
+	      maximum-pool-size: 30
 ----
 
 TIP: Spring Boot will expose Hikari-specific settings to `spring.datasource.hikari`.
@@ -1599,17 +1655,22 @@ TIP: `firstDataSourceProperties` has to be flagged as `@Primary` so that the dat
 Both data sources are also bound for advanced customizations.
 For instance, you could configure them as follows:
 
-[source,properties,indent=0]
+[source,yaml,indent=0,configblocks]
 ----
-	app.datasource.first.url=jdbc:mysql://localhost/first
-	app.datasource.first.username=dbuser
-	app.datasource.first.password=dbpass
-	app.datasource.first.configuration.maximum-pool-size=30
+	app:
+	  datasource:
+	    first:
+	      url: "jdbc:mysql://localhost/first"
+	      username: "dbuser"
+	      password: "dbpass"
+	      configuration:
+	        maximum-pool-size: 30
 
-	app.datasource.second.url=jdbc:mysql://localhost/second
-	app.datasource.second.username=dbuser
-	app.datasource.second.password=dbpass
-	app.datasource.second.max-total=30
+	    second:
+	      url: "jdbc:mysql://localhost/second"
+	      username: "dbuser"
+	      password: "dbpass"
+	      max-total: 30
 ----
 
 You can apply the same concept to the secondary `DataSource` as well, as shown in the following example:
@@ -1673,10 +1734,14 @@ If you prefer to set the dialect yourself, set the configprop:spring.jpa.databas
 
 The most common options to set are shown in the following example:
 
-[indent=0,subs="verbatim,quotes,attributes"]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.jpa.hibernate.naming.physical-strategy=com.example.MyPhysicalNamingStrategy
-	spring.jpa.show-sql=true
+	spring:
+	  jpa:
+	    hibernate:
+	      naming:
+	        physical-strategy: "com.example.MyPhysicalNamingStrategy"
+	    show-sql: true
 ----
 
 In addition, all properties in `+spring.jpa.properties.*+` are passed through as normal JPA properties (with the prefix stripped) when the local `EntityManagerFactory` is created.
@@ -1993,12 +2058,14 @@ Spring Boot can detect your database type and execute those scripts on startup.
 If you use an embedded database, this happens by default.
 You can also enable it for any database type, as shown in the following example:
 
-[indent=0,subs="verbatim,quotes,attributes"]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.batch.initialize-schema=always
+	spring:
+	  batch:
+	    initialize-schema: "always"
 ----
 
-You can also switch off the initialization explicitly by setting `spring.batch.initialize-schema=never`.
+You can also switch off the initialization explicitly by setting `spring.batch.initialize-schema` to `never`.
 
 
 
@@ -2017,17 +2084,21 @@ By default, they are in a directory called `classpath:db/migration`, but you can
 This is a comma-separated list of one or more `classpath:` or `filesystem:` locations.
 For example, the following configuration would search for scripts in both the default classpath location and the `/opt/migration` directory:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.flyway.locations=classpath:db/migration,filesystem:/opt/migration
+	spring:
+	  flyway:
+	    locations: "classpath:db/migration,filesystem:/opt/migration"
 ----
 
 You can also add a special `\{vendor}` placeholder to use vendor-specific scripts.
 Assume the following:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.flyway.locations=classpath:db/migration/{vendor}
+	spring:
+	  flyway:
+	    locations: "classpath:db/migration/{vendor}"
 ----
 
 Rather than using `db/migration`, the preceding configuration sets the directory to use according to the type of the database (such as `db/migration/mysql` for MySQL).
@@ -2061,9 +2132,11 @@ For example, you can place test-specific migrations in `src/test/resources` and
 Also, you can use profile-specific configuration to customize `spring.flyway.locations` so that certain migrations run only when a particular profile is active.
 For example, in `application-dev.properties`, you might specify the following setting:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.flyway.locations=classpath:/db/migration,classpath:/dev/db/migration
+	spring:
+	  flyway:
+	    locations: "classpath:/db/migration,classpath:/dev/db/migration"
 ----
 
 With that setup, migrations in `dev/db/migration` run only when the `dev` profile is active.
@@ -2287,10 +2360,13 @@ If you use Tomcat as a servlet container, then Spring Boot adds Tomcat's own `Re
 The standard behavior is determined by the presence or absence of certain request headers (`x-forwarded-for` and `x-forwarded-proto`), whose names are conventional, so it should work with most front-end proxies.
 You can switch on the valve by adding some entries to `application.properties`, as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	server.tomcat.remoteip.remote-ip-header=x-forwarded-for
-	server.tomcat.remoteip.protocol-header=x-forwarded-proto
+	server:
+	  tomcat:
+	    remoteip:
+	      remote-ip-header: "x-forwarded-for"
+	      protocol-header: "x-forwarded-proto"
 ----
 
 (The presence of either of those properties switches on the valve.
diff --git a/spring-boot-project/spring-boot-docs/src/docs/asciidoc/production-ready-features.adoc b/spring-boot-project/spring-boot-docs/src/docs/asciidoc/production-ready-features.adoc
index f2684b6e4f..9d1d7989a0 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/asciidoc/production-ready-features.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/asciidoc/production-ready-features.adoc
@@ -161,18 +161,25 @@ By default, all endpoints except for `shutdown` are enabled.
 To configure the enablement of an endpoint, use its `management.endpoint.<id>.enabled` property.
 The following example enables the `shutdown` endpoint:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.endpoint.shutdown.enabled=true
+	management:
+	  endpoint:
+	    shutdown:
+	      enabled: true
 ----
 
 If you prefer endpoint enablement to be opt-in rather than opt-out, set the configprop:management.endpoints.enabled-by-default[] property to `false` and use individual endpoint `enabled` properties to opt back in.
 The following example enables the `info` endpoint and disables all other endpoints:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.endpoints.enabled-by-default=false
-	management.endpoint.info.enabled=true
+	management:
+	  endpoints:
+	    enabled-by-default: false
+	  endpoint:
+	    info:
+	      enabled: true
 ----
 
 NOTE: Disabled endpoints are removed entirely from the application context.
@@ -312,33 +319,29 @@ Both `include` and `exclude` properties can be configured with a list of endpoin
 
 For example, to stop exposing all endpoints over JMX and only expose the `health` and `info` endpoints, use the following property:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.endpoints.jmx.exposure.include=health,info
+	management:
+	  endpoints:
+	    jmx:
+	      exposure:
+	        include: "health,info"
 ----
 
 `*` can be used to select all endpoints.
 For example, to expose everything over HTTP except the `env` and `beans` endpoints, use the following properties:
 
-[source,properties,indent=0,configprops]
-----
-	management.endpoints.web.exposure.include=*
-	management.endpoints.web.exposure.exclude=env,beans
-----
-
-[NOTE]
-====
-`*` has a special meaning in YAML, so be sure to add quotes if you want to include (or exclude) all endpoints, as shown in the following example:
-
-[source,yaml,indent=0]
+[source,yaml,indent=0,configprops,configblocks]
 ----
 	management:
 	  endpoints:
 	    web:
 	      exposure:
 	        include: "*"
+	        exclude: "env,beans"
 ----
-====
+
+NOTE: `*` has a special meaning in YAML, so be sure to add quotes if you want to include (or exclude) all endpoints.
 
 NOTE: If your application is exposed publicly, we strongly recommend that you also <<production-ready-endpoints-security, secure your endpoints>>.
 
@@ -377,9 +380,13 @@ If you deploy applications behind a firewall, you may prefer that all your actua
 You can do so by changing the configprop:management.endpoints.web.exposure.include[] property, as follows:
 
 .application.properties
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.endpoints.web.exposure.include=*
+	management:
+	  endpoints:
+	    web:
+	      exposure:
+	        include: "*"
 ----
 
 Additionally, if Spring Security is present, you would need to add custom security configuration that allows unauthenticated access to the endpoints as shown in the following example:
@@ -407,9 +414,13 @@ To configure the amount of time for which an endpoint will cache a response, use
 The following example sets the time-to-live of the `beans` endpoint's cache to 10 seconds:
 
 .application.properties
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.endpoint.beans.cache.time-to-live=10s
+	management:
+	  endpoint:
+	    beans:
+	      cache:
+	        time-to-live: "10s"
 ----
 
 NOTE: The prefix `management.endpoint.<name>` is used to uniquely identify the endpoint that is being configured.
@@ -435,10 +446,14 @@ If you use Spring MVC or Spring WebFlux, Actuator's web endpoints can be configu
 CORS support is disabled by default and is only enabled once the configprop:management.endpoints.web.cors.allowed-origins[] property has been set.
 The following configuration permits `GET` and `POST` calls from the `example.com` domain:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.endpoints.web.cors.allowed-origins=https://example.com
-	management.endpoints.web.cors.allowed-methods=GET,POST
+	management:
+	  endpoints:
+	    web:
+	      cors:
+	        allowed-origins: "https://example.com"
+	        allowed-methods: "GET,POST"
 ----
 
 TIP: See {spring-boot-actuator-autoconfigure-module-code}/endpoint/web/CorsEndpointProperties.java[CorsEndpointProperties] for a complete list of options.
@@ -798,9 +813,13 @@ In such cases, a custom implementation of the {spring-boot-actuator-module-code}
 For example, assume a new `Status` with code `FATAL` is being used in one of your `HealthIndicator` implementations.
 To configure the severity order, add the following property to your application properties:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.endpoint.health.status.order=fatal,down,out-of-service,unknown,up
+	management:
+	  endpoint:
+	    health:
+	      status:
+	        order: "fatal,down,out-of-service,unknown,up"
 ----
 
 The HTTP status code in the response reflects the overall health status.
@@ -811,11 +830,16 @@ Configuring a custom mapping disables the defaults mappings for `DOWN` and `OUT_
 If you want to retain the default mappings they must be configured explicitly alongside any custom mappings.
 For example, the following property maps `FATAL` to 503 (service unavailable) and retains the default mappings for `DOWN` and `OUT_OF_SERVICE`:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.endpoint.health.status.http-mapping.down=503
-	management.endpoint.health.status.http-mapping.fatal=503
-	management.endpoint.health.status.http-mapping.out-of-service=503
+	management:
+	  endpoint:
+	    health:
+	      status:
+	        http-mapping:
+	          down: 503
+	          fatal: 503
+	          out-of-service: 503
 ----
 
 TIP: If you need more control, you can define your own `HttpCodeStatusMapper` bean.
@@ -908,30 +932,47 @@ It's sometimes useful to organize health indicators into groups that can be used
 To create a health indicator group you can use the `management.endpoint.health.group.<name>` property and specify a list of health indicator IDs to `include` or `exclude`.
 For example, to create a group that includes only database indicators you can define the following:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.endpoint.health.group.custom.include=db
+	management:
+	  endpoint:
+	    health:
+	      group:
+	        custom:
+	          include: "db"
 ----
 
 You can then check the result by hitting `http://localhost:8080/actuator/health/custom`.
 
 Similarly, to create a group that excludes the database indicators from the group and includes all the other indicators, you can define the following:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.endpoint.health.group.custom.exclude=db
+	management:
+	  endpoint:
+	    health:
+	      group:
+	        custom:
+	          exclude: "db"
 ----
 
 By default groups will inherit the same `StatusAggregator` and `HttpCodeStatusMapper` settings as the system health, however, these can also be defined on a per-group basis.
 It's also possible to override the `show-details` and `roles` properties if required:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.endpoint.health.group.custom.show-details=when-authorized
-	management.endpoint.health.group.custom.roles=admin
-	management.endpoint.health.group.custom.status.order=fatal,up
-	management.endpoint.health.group.custom.status.http-mapping.fatal=500
-	management.endpoint.health.group.custom.status.http-mapping.out-of-service=500
+	management:
+	  endpoint:
+	    health:
+	      group:
+	        custom:
+	          show-details: "when-authorized"
+	          roles: "admin"
+	          status:
+	            order: "fatal,up"
+	            http-mapping:
+	              fatal: 500
+	              out-of-service: 500
 ----
 
 TIP: You can use `@Qualifier("groupname")` if you need to register custom `StatusAggregator` or `HttpCodeStatusMapper` beans for use with the group.
@@ -986,9 +1027,14 @@ In this case, a probe check could be successful even if the main application doe
 Actuator configures the "liveness" and "readiness" probes as Health Groups; this means that all the <<production-ready-health-groups, Health Groups features>> are available for them.
 You can, for example, configure additional Health Indicators:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.endpoint.health.group.readiness.include=readinessState,customCheck
+	management:
+	  endpoint:
+	    health:
+	      group:
+	        readiness:
+	          include: "readinessState,customCheck"
 ----
 
 By default, Spring Boot does not add other Health Indicators to these groups.
@@ -1101,11 +1147,14 @@ You can customize the data exposed by the `info` endpoint by setting `+info.*+`
 All `Environment` properties under the `info` key are automatically exposed.
 For example, you could add the following settings to your `application.properties` file:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	info.app.encoding=UTF-8
-	info.app.java.source=1.8
-	info.app.java.target=1.8
+	info:
+	  app:
+	    encoding: "UTF-8"
+	    java:
+	      source: "11"
+	      target: "11"
 ----
 
 [TIP]
@@ -1114,11 +1163,14 @@ Rather than hardcoding those values, you could also <<howto.adoc#howto-automatic
 
 Assuming you use Maven, you could rewrite the preceding example as follows:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	info.app.encoding=@project.build.sourceEncoding@
-	info.app.java.source=@java.version@
-	info.app.java.target=@java.version@
+	info:
+	  app:
+	    encoding: "@project.build.sourceEncoding@"
+	    java:
+	      source: "@java.version@"
+	      target: "@java.version@"
 ----
 ====
 
@@ -1134,9 +1186,12 @@ See "<<howto.adoc#howto-git-info,Generate git information>>" for more details.
 
 If you want to display the full git information (that is, the full content of `git.properties`), use the configprop:management.info.git.mode[] property, as follows:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.info.git.mode=full
+	management:
+	  info:
+	    git:
+	      mode: "full"
 ----
 
 
@@ -1209,9 +1264,12 @@ Sometimes, it is useful to customize the prefix for the management endpoints.
 For example, your application might already use `/actuator` for another purpose.
 You can use the configprop:management.endpoints.web.base-path[] property to change the prefix for your management endpoint, as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.endpoints.web.base-path=/manage
+	management:
+	  endpoints:
+	    web:
+	      base-path: "/manage"
 ----
 
 The preceding `application.properties` example changes the endpoint from `/actuator/\{id}` to `/manage/\{id}` (for example, `/manage/info`).
@@ -1224,10 +1282,14 @@ If you want to map endpoints to a different path, you can use the configprop:man
 The following example remaps `/actuator/health` to `/healthcheck`:
 
 .application.properties
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.endpoints.web.base-path=/
-	management.endpoints.web.path-mapping.health=healthcheck
+	management:
+	  endpoints:
+	    web:
+	      base-path: "/"
+	      path-mapping:
+	        health: "healthcheck"
 ----
 
 
@@ -1239,9 +1301,11 @@ If, however, your application runs inside your own data center, you may prefer t
 
 You can set the configprop:management.server.port[] property to change the HTTP port, as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.server.port=8081
+	management:
+	  server:
+	    port: 8081
 ----
 
 NOTE: On Cloud Foundry, applications only receive requests on port 8080 for both HTTP and TCP routing, by default.
@@ -1254,28 +1318,38 @@ If you want to use a custom management port on Cloud Foundry, you will need to e
 When configured to use a custom port, the management server can also be configured with its own SSL by using the various `management.server.ssl.*` properties.
 For example, doing so lets a management server be available over HTTP while the main application uses HTTPS, as shown in the following property settings:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	server.port=8443
-	server.ssl.enabled=true
-	server.ssl.key-store=classpath:store.jks
-	server.ssl.key-password=secret
-	management.server.port=8080
-	management.server.ssl.enabled=false
+	server:
+	  port: 8443
+	  ssl:
+	    enabled: true
+	    key-store: "classpath:store.jks"
+	    key-password: secret
+	management:
+	  server:
+	    port: 8080
+	    ssl:
+	      enabled: false
 ----
 
 Alternatively, both the main server and the management server can use SSL but with different key stores, as follows:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	server.port=8443
-	server.ssl.enabled=true
-	server.ssl.key-store=classpath:main.jks
-	server.ssl.key-password=secret
-	management.server.port=8080
-	management.server.ssl.enabled=true
-	management.server.ssl.key-store=classpath:management.jks
-	management.server.ssl.key-password=secret
+	server:
+	  port: 8443
+	  ssl:
+	    enabled: true
+	    key-store: "classpath:main.jks"
+	    key-password: "secret"
+	management:
+	  server:
+	    port: 8080
+	    ssl:
+	      enabled: true
+	      key-store: "classpath:management.jks"
+	      key-password: "secret"
 ----
 
 
@@ -1289,10 +1363,12 @@ NOTE: You can listen on a different address only when the port differs from the
 
 The following example `application.properties` does not allow remote management connections:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.server.port=8081
-	management.server.address=127.0.0.1
+	management:
+	  server:
+	    port: 8081
+	    address: "127.0.0.1"
 ----
 
 
@@ -1301,16 +1377,22 @@ The following example `application.properties` does not allow remote management
 === Disabling HTTP Endpoints
 If you do not want to expose endpoints over HTTP, you can set the management port to `-1`, as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.server.port=-1
+	management:
+	  server:
+	    port: -1
 ----
 
 This can be achieved using the configprop:management.endpoints.web.exposure.exclude[] property as well, as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.endpoints.web.exposure.exclude=*
+	management:
+	  endpoints:
+	    web:
+	      exposure:
+	        exclude: "*"
 ----
 
 
@@ -1334,10 +1416,15 @@ To solve this problem, you can set the configprop:spring.jmx.unique-names[] prop
 You can also customize the JMX domain under which endpoints are exposed.
 The following settings show an example of doing so in `application.properties`:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.jmx.unique-names=true
-	management.endpoints.jmx.domain=com.example.myapp
+	spring:
+	  jmx:
+	    unique-names: true
+	management:
+	  endpoints:
+	    jmx:
+	      domain: "com.example.myapp"
 ----
 
 
@@ -1346,9 +1433,13 @@ The following settings show an example of doing so in `application.properties`:
 === Disabling JMX Endpoints
 If you do not want to expose endpoints over JMX, you can set the configprop:management.endpoints.jmx.exposure.exclude[] property to `*`, as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.endpoints.jmx.exposure.exclude=*
+	management:
+	  endpoints:
+	    jmx:
+	      exposure:
+	        exclude: "*"
 ----
 
 
@@ -1382,9 +1473,13 @@ Jolokia has a number of settings that you would traditionally configure by setti
 With Spring Boot, you can use your `application.properties` file.
 To do so, prefix the parameter with `management.endpoint.jolokia.config.`, as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.endpoint.jolokia.config.debug=true
+	management:
+	  endpoint:
+	    jolokia:
+	      config:
+	        debug: true
 ----
 
 
@@ -1393,9 +1488,12 @@ To do so, prefix the parameter with `management.endpoint.jolokia.config.`, as sh
 ==== Disabling Jolokia
 If you use Jolokia but do not want Spring Boot to configure it, set the configprop:management.endpoint.jolokia.enabled[] property to `false`, as follows:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.endpoint.jolokia.enabled=false
+	management:
+	  endpoint:
+	    jolokia:
+	      enabled: false
 ----
 
 
@@ -1470,23 +1568,33 @@ Most registries share common features.
 For instance, you can disable a particular registry even if the Micrometer registry implementation is on the classpath.
 For example, to disable Datadog:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.metrics.export.datadog.enabled=false
+	management:
+	  metrics:
+	    export:
+	      datadog:
+	        enabled: false
 ----
 
 You can also disable all registries unless stated otherwise by the registry-specific property, as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.metrics.export.defaults.enabled=false
+	management:
+	  metrics:
+	    export:
+	      defaults:
+	        enabled: false
 ----
 
 Spring Boot will also add any auto-configured registries to the global static composite registry on the `Metrics` class unless you explicitly tell it not to:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.metrics.use-global-registry=false
+	management:
+	  metrics:
+	    use-global-registry: false
 ----
 
 You can register any number of `MeterRegistryCustomizer` beans to further configure the registry, such as applying common tags, before any meters are registered with the registry:
@@ -1523,9 +1631,13 @@ Spring Boot also <<production-ready-metrics-meter,configures built-in instrument
 By default, the AppOptics registry pushes metrics to `https://api.appoptics.com/v1/measurements` periodically.
 To export metrics to SaaS {micrometer-registry-docs}/appOptics[AppOptics], your API token must be provided:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.metrics.export.appoptics.api-token=YOUR_TOKEN
+	management:
+	  metrics:
+	    export:
+	      appoptics:
+	        api-token: "YOUR_TOKEN"
 ----
 
 
@@ -1535,9 +1647,13 @@ To export metrics to SaaS {micrometer-registry-docs}/appOptics[AppOptics], your
 By default, metrics are exported to {micrometer-registry-docs}/atlas[Atlas] running on your local machine.
 The location of the https://github.com/Netflix/atlas[Atlas server] to use can be provided using:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.metrics.export.atlas.uri=https://atlas.example.com:7101/api/v1/publish
+	management:
+	  metrics:
+	    export:
+	      atlas:
+	        uri: "https://atlas.example.com:7101/api/v1/publish"
 ----
 
 
@@ -1547,16 +1663,24 @@ The location of the https://github.com/Netflix/atlas[Atlas server] to use can be
 Datadog registry pushes metrics to https://www.datadoghq.com[datadoghq] periodically.
 To export metrics to {micrometer-registry-docs}/datadog[Datadog], your API key must be provided:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.metrics.export.datadog.api-key=YOUR_KEY
+	management:
+	  metrics:
+	    export:
+	      datadog:
+	        api-key: "YOUR_KEY"
 ----
 
 You can also change the interval at which metrics are sent to Datadog:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.metrics.export.datadog.step=30s
+	management:
+	  metrics:
+	    export:
+	      datadog:
+	        step: "30s"
 ----
 
 
@@ -1566,18 +1690,26 @@ You can also change the interval at which metrics are sent to Datadog:
 Dynatrace registry pushes metrics to the configured URI periodically.
 To export metrics to {micrometer-registry-docs}/dynatrace[Dynatrace], your API token, device ID, and URI must be provided:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.metrics.export.dynatrace.api-token=YOUR_TOKEN
-	management.metrics.export.dynatrace.device-id=YOUR_DEVICE_ID
-	management.metrics.export.dynatrace.uri=YOUR_URI
+	management:
+	  metrics:
+	    export:
+	      dynatrace:
+	        api-token: "YOUR_TOKEN"
+	        device-id: "YOUR_DEVICE_ID"
+	        uri: "YOUR_URI"
 ----
 
 You can also change the interval at which metrics are sent to Dynatrace:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.metrics.export.dynatrace.step=30s
+	management:
+	  metrics:
+	    export:
+	      dynatrace:
+	        step: "30s"
 ----
 
 
@@ -1587,9 +1719,13 @@ You can also change the interval at which metrics are sent to Dynatrace:
 By default, metrics are exported to {micrometer-registry-docs}/elastic[Elastic] running on your local machine.
 The location of the Elastic server to use can be provided using the following property:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.metrics.export.elastic.host=https://elastic.example.com:8086
+	management:
+	  metrics:
+	    export:
+	      elastic:
+	        host: "https://elastic.example.com:8086"
 ----
 
 
@@ -1599,10 +1735,14 @@ The location of the Elastic server to use can be provided using the following pr
 By default, metrics are exported to {micrometer-registry-docs}/ganglia[Ganglia] running on your local machine.
 The http://ganglia.sourceforge.net[Ganglia server] host and port to use can be provided using:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.metrics.export.ganglia.host=ganglia.example.com
-	management.metrics.export.ganglia.port=9649
+	management:
+	  metrics:
+	    export:
+	      ganglia:
+	        host: "ganglia.example.com"
+	        port: 9649
 ----
 
 
@@ -1612,10 +1752,14 @@ The http://ganglia.sourceforge.net[Ganglia server] host and port to use can be p
 By default, metrics are exported to {micrometer-registry-docs}/graphite[Graphite] running on your local machine.
 The https://graphiteapp.org[Graphite server] host and port to use can be provided using:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.metrics.export.graphite.host=graphite.example.com
-	management.metrics.export.graphite.port=9004
+	management:
+	  metrics:
+	     export:
+	       graphite:
+	         host: "graphite.example.com"
+	         port: 9004
 ----
 
 Micrometer provides a default `HierarchicalNameMapper` that governs how a dimensional meter id is {micrometer-registry-docs}/graphite#_hierarchical_name_mapping[mapped to flat hierarchical names].
@@ -1638,17 +1782,26 @@ public GraphiteMeterRegistry graphiteMeterRegistry(GraphiteConfig config, Clock
 By default, the Humio registry pushes metrics to https://cloud.humio.com periodically.
 To export metrics to SaaS {micrometer-registry-docs}/humio[Humio], your API token must be provided:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.metrics.export.humio.api-token=YOUR_TOKEN
+	management:
+	  metrics:
+	    export:
+	      humio:
+	        api-token: "YOUR_TOKEN"
 ----
 
 You should also configure one or more tags to identify the data source to which metrics will be pushed:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.metrics.export.humio.tags.alpha=a
-	management.metrics.export.humio.tags.bravo=b
+	management:
+	  metrics:
+	    export:
+	      humio:
+	        tags:
+	          alpha: "a"
+	          bravo: "b"
 ----
 
 
@@ -1658,9 +1811,13 @@ You should also configure one or more tags to identify the data source to which
 By default, metrics are exported to {micrometer-registry-docs}/influx[Influx] running on your local machine.
 The location of the https://www.influxdata.com[Influx server] to use can be provided using:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.metrics.export.influx.uri=https://influx.example.com:8086
+	management:
+	  metrics:
+	    export:
+	      influx:
+	        uri: "https://influx.example.com:8086"
 ----
 
 
@@ -1671,9 +1828,13 @@ Micrometer provides a hierarchical mapping to {micrometer-registry-docs}/jmx[JMX
 By default, metrics are exported to the `metrics` JMX domain.
 The domain to use can be provided using:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.metrics.export.jmx.domain=com.example.app.metrics
+	management:
+	  metrics:
+	    export:
+	      jmx:
+	        domain: "com.example.app.metrics"
 ----
 
 Micrometer provides a default `HierarchicalNameMapper` that governs how a dimensional meter id is {micrometer-registry-docs}/jmx#_hierarchical_name_mapping[mapped to flat hierarchical names].
@@ -1696,9 +1857,13 @@ public JmxMeterRegistry jmxMeterRegistry(JmxConfig config, Clock clock) {
 By default, metrics are exported to {micrometer-registry-docs}/kairos[KairosDB] running on your local machine.
 The location of the https://kairosdb.github.io/[KairosDB server] to use can be provided using:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.metrics.export.kairos.uri=https://kairosdb.example.com:8080/api/v1/datapoints
+	management:
+	  metrics:
+	    export:
+	      kairos:
+	        uri: "https://kairosdb.example.com:8080/api/v1/datapoints"
 ----
 
 
@@ -1708,24 +1873,36 @@ The location of the https://kairosdb.github.io/[KairosDB server] to use can be p
 New Relic registry pushes metrics to {micrometer-registry-docs}/new-relic[New Relic] periodically.
 To export metrics to https://newrelic.com[New Relic], your API key and account id must be provided:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.metrics.export.newrelic.api-key=YOUR_KEY
-	management.metrics.export.newrelic.account-id=YOUR_ACCOUNT_ID
+	management:
+	  metrics:
+	    export:
+	      newrelic:
+	        api-key: "YOUR_KEY"
+	        account-id: "YOUR_ACCOUNT_ID"
 ----
 
 You can also change the interval at which metrics are sent to New Relic:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.metrics.export.newrelic.step=30s
+	management:
+	  metrics:
+	    export:
+	      newrelic:
+	        step: "30s"
 ----
 
 By default, metrics are published via REST calls but it is also possible to use the Java Agent API if you have it on the classpath:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.metrics.export.newrelic.client-provider-type=insights-agent
+	management:
+	  metrics:
+	    export:
+	      newrelic:
+	        client-provider-type: "insights-agent"
 ----
 
 Finally, you can take full control by defining your own `NewRelicClientProvider` bean.
@@ -1774,16 +1951,24 @@ For advanced configuration, you can also provide your own `PrometheusPushGateway
 SignalFx registry pushes metrics to {micrometer-registry-docs}/signalFx[SignalFx] periodically.
 To export metrics to https://www.signalfx.com[SignalFx], your access token must be provided:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.metrics.export.signalfx.access-token=YOUR_ACCESS_TOKEN
+	management:
+	  metrics:
+	    export:
+	      signalfx:
+	        access-token: "YOUR_ACCESS_TOKEN"
 ----
 
 You can also change the interval at which metrics are sent to SignalFx:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.metrics.export.signalfx.step=30s
+	management:
+	  metrics:
+	    export:
+	      signalfx:
+	        step: "30s"
 ----
 
 
@@ -1796,9 +1981,13 @@ This allows you to see what metrics are collected in the <<production-ready-metr
 The in-memory backend disables itself as soon as you're using any of the other available backend.
 You can also disable it explicitly:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.metrics.export.simple.enabled=false
+	management:
+	  metrics:
+	    export:
+	      simple:
+	        enabled: false
 ----
 
 
@@ -1808,16 +1997,24 @@ You can also disable it explicitly:
 Stackdriver registry pushes metrics to https://cloud.google.com/stackdriver/[Stackdriver] periodically.
 To export metrics to SaaS {micrometer-registry-docs}/stackdriver[Stackdriver], your Google Cloud project id must be provided:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.metrics.export.stackdriver.project-id=my-project
+	management:
+	  metrics:
+	    export:
+	      stackdriver:
+	        project-id: "my-project"
 ----
 
 You can also change the interval at which metrics are sent to Stackdriver:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.metrics.export.stackdriver.step=30s
+	management:
+	  metrics:
+	    export:
+	      stackdriver:
+	        step: "30s"
 ----
 
 
@@ -1828,18 +2025,26 @@ The StatsD registry pushes metrics over UDP to a StatsD agent eagerly.
 By default, metrics are exported to a {micrometer-registry-docs}/statsD[StatsD] agent running on your local machine.
 The StatsD agent host, port, and protocol to use can be provided using:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.metrics.export.statsd.host=statsd.example.com
-	management.metrics.export.statsd.port=9125
-	management.metrics.export.statsd.protocol=udp
+	management:
+	  metrics:
+	    export:
+	      statsd:
+	        host: "statsd.example.com"
+	        port: 9125
+	        protocol: "udp"
 ----
 
 You can also change the StatsD line protocol to use (default to Datadog):
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.metrics.export.statsd.flavor=etsy
+	management:
+	  metrics:
+	    export:
+	      statsd:
+	        flavor: "etsy"
 ----
 
 
@@ -1849,25 +2054,37 @@ You can also change the StatsD line protocol to use (default to Datadog):
 Wavefront registry pushes metrics to {micrometer-registry-docs}/wavefront[Wavefront] periodically.
 If you are exporting metrics to https://www.wavefront.com/[Wavefront] directly, your API token must be provided:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.metrics.export.wavefront.api-token=YOUR_API_TOKEN
+	management:
+	  metrics:
+	    export:
+	      wavefront:
+	        api-token: "YOUR_API_TOKEN"
 ----
 
 Alternatively, you may use a Wavefront sidecar or an internal proxy set up in your environment that forwards metrics data to the Wavefront API host:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.metrics.export.wavefront.uri=proxy://localhost:2878
+	management:
+	  metrics:
+	    export:
+	      wavefront:
+	        uri: "proxy://localhost:2878"
 ----
 
 TIP: If publishing metrics to a Wavefront proxy (as described in https://docs.wavefront.com/proxies_installing.html[the documentation]), the host must be in the `proxy://HOST:PORT` format.
 
 You can also change the interval at which metrics are sent to Wavefront:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.metrics.export.wavefront.step=30s
+	management:
+	  metrics:
+	    export:
+	      wavefront:
+	        step: "30s"
 ----
 
 
@@ -2119,9 +2336,12 @@ Metrics are also tagged by the name of the `EntityManagerFactory` that is derive
 To enable statistics, the standard JPA property `hibernate.generate_statistics` must be set to `true`.
 You can enable that on the auto-configured `EntityManagerFactory` as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.jpa.properties.hibernate.generate_statistics=true
+	spring:
+	  jpa:
+	    properties:
+	      "[hibernate.generate_statistics]": true
 ----
 
 
@@ -2180,10 +2400,13 @@ include::{code-examples}/actuate/metrics/MetricsFilterBeanExample.java[tag=confi
 Common tags are generally used for dimensional drill-down on the operating environment like host, instance, region, stack, etc.
 Commons tags are applied to all meters and can be configured as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.metrics.tags.region=us-east-1
-	management.metrics.tags.stack=prod
+	management:
+	  metrics:
+	    tags:
+	      region: "us-east-1"
+	      stack: "prod"
 ----
 
 The example above adds `region` and `stack` tags to all meters with a value of `us-east-1` and `prod` respectively.
@@ -2198,9 +2421,13 @@ In addition to `MeterFilter` beans, it's also possible to apply a limited set of
 Per-meter customizations apply to any all meter IDs that start with the given name.
 For example, the following will disable any meters that have an ID starting with `example.remote`
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.metrics.enable.example.remote=false
+	management:
+	  metrics:
+	    enable:
+	      example:
+	        remote: false
 ----
 
 The following properties allow per-meter customization:
@@ -2347,9 +2574,11 @@ If you want to fully disable the `/cloudfoundryapplication` endpoints, you can a
 
 
 .application.properties
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.cloudfoundry.enabled=false
+	management:
+	  cloudfoundry:
+	    enabled: false
 ----
 
 
@@ -2360,9 +2589,11 @@ By default, the security verification for `/cloudfoundryapplication` endpoints m
 If your Cloud Foundry UAA or Cloud Controller services use self-signed certificates, you need to set the following property:
 
 .application.properties
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	management.cloudfoundry.skip-ssl-validation=true
+	management:
+	  cloudfoundry:
+	    skip-ssl-validation: true
 ----
 
 
diff --git a/spring-boot-project/spring-boot-docs/src/docs/asciidoc/spring-boot-features.adoc b/spring-boot-project/spring-boot-docs/src/docs/asciidoc/spring-boot-features.adoc
index 384f227bc6..169a7f75cd 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/asciidoc/spring-boot-features.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/asciidoc/spring-boot-features.adoc
@@ -96,9 +96,11 @@ For these reasons, lazy initialization is not enabled by default and it is recom
 Lazy initialization can be enabled programmatically using the `lazyInitialization` method on `SpringApplicationBuilder` or the `setLazyInitialization` method on `SpringApplication`.
 Alternatively, it can be enabled using the configprop:spring.main.lazy-initialization[] property as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.main.lazy-initialization=true
+	spring:
+	  main:
+	    lazy-initialization: true
 ----
 
 TIP: If you want to disable lazy initialization for certain beans while using lazy initialization for the rest of the application, you can explicitly set their lazy attribute to false using the `@Lazy(false)` annotation.
@@ -713,10 +715,13 @@ Imports are processed as they are discovered, and are treated as an additional d
 
 For example, you might have the following in your classpath `application.properties` file:
 
-[source,properties,indent=0]
+[source,yaml,indent=0,configblocks]
 ----
-	spring.application.name=myapp
-	spring.config.import=optional:file:./dev.properties
+	spring:
+	  application:
+	    name: "myapp"
+	  config:
+	    import: "optional:file:./dev.properties"
 ----
 
 This will trigger the import of a `dev.properties` file in current directory (if such a file exists).
@@ -747,9 +752,11 @@ You can do this by putting an extension hint in square brackets.
 For example, suppose you have a `/etc/config/myconfig` file that you wish to import as yaml.
 You can import it from your `application.properties` using the following:
 
-[source,properties,indent=0]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.config.import=file:/etc/config/myconfig[.yaml]
+	spring:
+	  config:
+	    import: "file:/etc/config/myconfig[.yaml]"
 ----
 
 
@@ -783,11 +790,13 @@ As an example, let's imagine that Kubernetes has mounted the following volume:
 
 The contents of the `username` file would be a config value, and the contents of `password` would be a secret.
 
-To import these properties, you can add the following to your `application.properties` file:
+To import these properties, you can add the following to your `application.properties` or `application.yaml` file:
 
-[source,properties,indent=0]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-spring.config.import=optional:configtree:/etc/config
+	spring:
+	  config:
+	    import: "optional:configtree:/etc/config"
 ----
 
 You can then access or inject `myapp.username` and `myapp.password` properties from the `Environment` in the usual way.
@@ -801,12 +810,13 @@ TIP: Configuration tree values can be bound to both string `String` and `byte[]`
 The values in `application.properties` and `application.yml` are filtered through the existing `Environment` when they are used, so you can refer back to previously defined values (for example, from System properties).
 The standard `$\{name}` property-placeholder syntax can be used anywhere within a value.
 
-For example, the following `application.properties` file will set `app.description` to "`MyApp is a Spring Boot application`":
+For example, the following file will set `app.description` to "`MyApp is a Spring Boot application`":
 
-[source,properties,indent=0]
+[source,yaml,indent=0,configblocks]
 ----
-	app.name=MyApp
-	app.description=${app.name} is a Spring Boot application
+	app:
+	  name: "MyApp"
+	  description: "${app.name} is a Spring Boot application"
 ----
 
 TIP: You can also use this technique to create "`short`" variants of existing Spring Boot properties.
@@ -873,13 +883,17 @@ The following activation properties are available:
 
 For example, the following specifies that the second document is only active when running on Kubernetes, and only when either the "`prod`" or "`staging`" profiles are active:
 
-[source,properties,indent=0]
+[source,yaml,indent=0,configblocks]
 ----
-	myprop=always-set
-	#---
-	spring.config.activate.on-cloud-platform=kubernetes
-	spring.config.activate.on-profile=prod | staging
-	myotherprop=sometimes-set
+	myprop:
+	  always-set
+	---
+	spring:
+	  config:
+	    activate:
+	      on-cloud-platform: "kubernetes"
+	      on-profile: "prod | staging"
+	myotherprop: sometimes-set
 ----
 
 
@@ -995,14 +1009,15 @@ Stick to using only one of them.
 The `RandomValuePropertySource` is useful for injecting random values (for example, into secrets or test cases).
 It can produce integers, longs, uuids, or strings, as shown in the following example:
 
-[source,properties,indent=0]
+[source,yaml,indent=0,configblocks]
 ----
-	my.secret=${random.value}
-	my.number=${random.int}
-	my.bignumber=${random.long}
-	my.uuid=${random.uuid}
-	my.number.less.than.ten=${random.int(10)}
-	my.number.in.range=${random.int[1024,65536]}
+	my:
+	  secret: "${random.value}"
+	  number: "${random.int}"
+	  bignumber: "${random.long}"
+	  uuid: "${random.uuid}"
+	  number-less-than-ten: "${random.int(10)}"
+	  number-in-range: "${random.int[1024,65536]}"
 ----
 
 The `+random.int*+` syntax is `OPEN value (,max) CLOSE` where the `OPEN,CLOSE` are any character and `value,max` are integers.
@@ -1271,8 +1286,6 @@ This style of configuration works particularly well with the `SpringApplication`
 
 [source,yaml,indent=0]
 ----
-	# application.yml
-
 	acme:
 		remote-address: 192.168.1.1
 		security:
@@ -1280,8 +1293,6 @@ This style of configuration works particularly well with the `SpringApplication`
 			roles:
 			  - USER
 			  - ADMIN
-
-	# additional configuration as required
 ----
 
 To work with `@ConfigurationProperties` beans, you can inject them in the same way as any other bean, as shown in the following example:
@@ -1427,14 +1438,23 @@ When binding to `Map` properties, if the `key` contains anything other than lowe
 If the key is not surrounded by `[]`, any characters that are not alpha-numeric or `-` are removed.
 For example, consider binding the following properties to a `Map`:
 
-[source,yaml,indent=0]
+
+[source,properties,indent=0,role="primary"]
+.Properties
+----
+	acme.map.[/key1]=value1
+	acme.map.[/key2]=value2
+	acme.map./key3=value3
+----
+
+[source,yaml,indent=0,role="secondary"]
+.Yaml
 ----
 	acme:
 	  map:
 	    "[/key1]": value1
 	    "[/key2]": value2
-	    /key3: value3
-
+	    "/key3": value3
 ----
 
 The properties above will bind to a `Map` with `/key1`, `/key2` and `key3` as the keys in the map.
@@ -1442,6 +1462,7 @@ The properties above will bind to a `Map` with `/key1`, `/key2` and `key3` as th
 NOTE: For YAML files, the brackets need to be surrounded by quotes for the keys to be parsed properly.
 
 
+
 [[boot-features-external-config-relaxed-binding-from-environment-variables]]
 ===== Binding from Environment Variables
 Most operating systems impose strict rules around the names that can be used for environment variables.
@@ -1491,18 +1512,20 @@ The following example exposes a list of `MyPojo` objects from `AcmeProperties`:
 
 Consider the following configuration:
 
-[source,yaml,indent=0]
+[source,yaml,indent=0,configblocks]
 ----
 	acme:
 	  list:
-	    - name: my name
-	      description: my description
+	  - name: "my name"
+	    description: "my description"
 	---
 	spring:
-	  profiles: dev
+	  config:
+	    activate:
+	      on-profile: "dev"
 	acme:
 	  list:
-	    - name: my another name
+	  - name: "my another name"
 ----
 
 If the `dev` profile is not active, `AcmeProperties.list` contains one `MyPojo` entry, as previously defined.
@@ -1512,20 +1535,22 @@ This configuration _does not_ add a second `MyPojo` instance to the list, and it
 When a `List` is specified in multiple profiles, the one with the highest priority (and only that one) is used.
 Consider the following example:
 
-[source,yaml,indent=0]
+[source,yaml,indent=0,configblocks]
 ----
 	acme:
 	  list:
-	    - name: my name
-	      description: my description
-	    - name: another name
-	      description: another description
+	  - name: "my name"
+	    description: "my description"
+	  - name: "another name"
+	    description: "another description"
 	---
 	spring:
-	  profiles: dev
+	  config:
+	    activate:
+	      on-profile: "dev"
 	acme:
 	  list:
-	    - name: my another name
+	  - name: "my another name"
 ----
 
 In the preceding example, if the `dev` profile is active, `AcmeProperties.list` contains _one_ `MyPojo` entry (with a name of `my another name` and a description of `null`).
@@ -1551,29 +1576,31 @@ The following example exposes a `Map<String, MyPojo>` from `AcmeProperties`:
 
 Consider the following configuration:
 
-[source,yaml,indent=0]
+[source,yaml,indent=0,configblocks]
 ----
 	acme:
 	  map:
 	    key1:
-	      name: my name 1
-	      description: my description 1
+	      name: "my name 1"
+	      description: "my description 1"
 	---
 	spring:
-	  profiles: dev
+	  config:
+	    activate:
+	      on-profile: "dev"
 	acme:
 	  map:
 	    key1:
-	      name: dev name 1
+	      name: "dev name 1"
 	    key2:
-	      name: dev name 2
-	      description: dev description 2
+	      name: "dev name 2"
+	      description: "dev description 2"
 ----
 
 If the `dev` profile is not active, `AcmeProperties.map` contains one entry with key `key1` (with a name of `my name 1` and a description of `my description 1`).
 If the `dev` profile is enabled, however, `map` contains two entries with keys `key1` (with a name of `dev name 1` and a description of `my description 1`) and `key2` (with a name of `dev name 2` and a description of `dev description 2`).
 
-NOTE: The preceding merging rules apply to properties from all property sources and not just YAML files.
+NOTE: The preceding merging rules apply to properties from all property sources, and not just files.
 
 
 
@@ -1813,9 +1840,11 @@ You can use a configprop:spring.profiles.active[] `Environment` property to spec
 You can specify the property in any of the ways described earlier in this chapter.
 For example, you could include it in your `application.properties`, as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.profiles.active=dev,hsqldb
+	spring:
+	  profiles:
+	    active: "dev,hsqldb"
 ----
 
 You could also specify it on the command line by using the following switch: `--spring.profiles.active=dev,hsqldb`.
@@ -1843,11 +1872,14 @@ A profile group allows you to define a logical name for a related group of profi
 
 For example, we can create a `production` group that consists of our `proddb` and `prodmq` profiles.
 
-[source,yaml,indent=0]
+[source,yaml,indent=0,configblocks]
 ----
-	spring.profiles.group.production:
-	  - proddb
-	  - prodmq
+	spring:
+	  profiles:
+	    group:
+	      production:
+	      - "proddb"
+	      - "prodmq"
 ----
 
 Our application can now be started using `--spring.profiles.active=production` to active the `production`, `proddb` and `prodmq` profiles in one hit.
@@ -2040,13 +2072,24 @@ The `root` logger can be configured by using `logging.level.root`.
 
 The following example shows potential logging settings in `application.properties`:
 
-[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
+[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops,role="primary"]
+.Properties
 ----
 	logging.level.root=warn
 	logging.level.org.springframework.web=debug
 	logging.level.org.hibernate=error
 ----
 
+[source,properties,indent=0,subs="verbatim,quotes,attributes",role="secondary"]
+.Yaml
+----
+	logging:
+	  level:
+	    root: "warn"
+	    org.springframework.web: "debug"
+	    org.hibernate: "error"
+----
+
 It's also possible to set logging levels using environment variables.
 For example, `LOGGING_LEVEL_ORG_SPRINGFRAMEWORK_WEB=DEBUG` will set `org.springframework.web` to `DEBUG`.
 
@@ -2064,16 +2107,20 @@ For example, you might commonly change the logging levels for _all_ Tomcat relat
 To help with this, Spring Boot allows you to define logging groups in your Spring `Environment`.
 For example, here's how you could define a "`tomcat`" group by adding it to your `application.properties`:
 
-[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
+[source,yaml,indent=0,subs="verbatim,quotes,attributes",configprops,configblocks]
 ----
-	logging.group.tomcat=org.apache.catalina, org.apache.coyote, org.apache.tomcat
+	logging:
+	  group:
+	    tomcat: "org.apache.catalina,org.apache.coyote,org.apache.tomcat"
 ----
 
 Once defined, you can change the level for all the loggers in the group with a single line:
 
-[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
+[source,yaml,indent=0,subs="verbatim,quotes,attributes",configprops,configblocks]
 ----
-	logging.level.tomcat=TRACE
+	logging:
+	  level:
+	    tomcat: "trace"
 ----
 
 Spring Boot includes the following pre-defined logging groups that can be used out-of-the-box:
@@ -2297,10 +2344,12 @@ If no properties file is found that matches any of the configured base names, th
 
 The basename of the resource bundle as well as several other attributes can be configured using the `spring.messages` namespace, as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.messages.basename=messages,config.i18n.messages
-	spring.messages.fallback-to-system-locale=false
+	spring:
+	  messages:
+	    basename: "messages,config.i18n.messages"
+	    fallback-to-system-locale: false
 ----
 
 TIP: `spring.messages.basename` supports comma-separated list of locations, either a package qualifier or a resource resolved from the classpath root.
@@ -2504,9 +2553,11 @@ Most of the time, this does not happen (unless you modify the default MVC config
 By default, resources are mapped on `+/**+`, but you can tune that with the configprop:spring.mvc.static-path-pattern[] property.
 For instance, relocating all resources to `/resources/**` can be achieved as follows:
 
-[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
+[source,yaml,indent=0,subs="verbatim,quotes,attributes",configprops,configblocks]
 ----
-	spring.mvc.static-path-pattern=/resources/**
+	spring:
+	  mvc:
+	    static-path-pattern: "/resources/**"
 ----
 
 You can also customize the static resource locations by using the configprop:spring.resources.static-locations[] property (replacing the default values with a list of directory locations).
@@ -2529,10 +2580,15 @@ Otherwise, all Webjars resolve as a `404`.
 
 To use cache busting, the following configuration configures a cache busting solution for all static resources, effectively adding a content hash, such as `<link href="/css/spring-2a2d595e6ed9a0b24f027f2b63b134d6.css"/>`, in URLs:
 
-[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
+[source,yaml,indent=0,subs="verbatim,quotes,attributes",configprops,configblocks]
 ----
-	spring.resources.chain.strategy.content.enabled=true
-	spring.resources.chain.strategy.content.paths=/**
+	spring:
+	  resources:
+	    chain:
+	      strategy:
+	        content:
+	          enabled: true
+	          paths: "/**"
 ----
 
 NOTE: Links to resources are rewritten in templates at runtime, thanks to a `ResourceUrlEncodingFilter` that is auto-configured for Thymeleaf and FreeMarker.
@@ -2543,13 +2599,19 @@ When loading resources dynamically with, for example, a JavaScript module loader
 That is why other strategies are also supported and can be combined.
 A "fixed" strategy adds a static version string in the URL without changing the file name, as shown in the following example:
 
-[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
+[source,yaml,indent=0,subs="verbatim,quotes,attributes",configprops,configblocks]
 ----
-	spring.resources.chain.strategy.content.enabled=true
-	spring.resources.chain.strategy.content.paths=/**
-	spring.resources.chain.strategy.fixed.enabled=true
-	spring.resources.chain.strategy.fixed.paths=/js/lib/
-	spring.resources.chain.strategy.fixed.version=v12
+	spring:
+	  resources:
+	    chain:
+	      strategy:
+	        content:
+	          enabled: true
+	          paths: "/**"
+	        fixed:
+	          enabled: true
+	          paths: "/js/lib/"
+	          version: "v12"
 ----
 
 With this configuration, JavaScript modules located under `"/js/lib/"` use a fixed versioning strategy (`"/v12/js/lib/mymodule.js"`), while other resources still use the content one (`<link href="/css/spring-2a2d595e6ed9a0b24f027f2b63b134d6.css"/>`).
@@ -2589,17 +2651,38 @@ Nowadays, Content Negotiation is much more reliable.
 There are other ways to deal with HTTP clients that don't consistently send proper "Accept" request headers.
 Instead of using suffix matching, we can use a query parameter to ensure that requests like `"GET /projects/spring-boot?format=json"` will be mapped to `@GetMapping("/projects/spring-boot")`:
 
+[source,yaml,indent=0,subs="verbatim,quotes,attributes",configblocks]
+----
+	spring:
+	  mvc:
+	    contentnegotiation:
+	      favor-parameter: true
+----
+
+Or if you prefer to use a different parameter name:
+
 [source,properties,indent=0,subs="verbatim,quotes,attributes"]
 ----
-	spring.mvc.contentnegotiation.favor-parameter=true
-
-	# We can change the parameter name, which is "format" by default:
-	# spring.mvc.contentnegotiation.parameter-name=myparam
-
-	# We can also register additional file extensions/media types with:
-	spring.mvc.contentnegotiation.media-types.markdown=text/markdown
+	spring:
+	  mvc:
+	    contentnegotiation:
+	      favor-parameter: true
+	      parameter-name: "myparam"
 ----
 
+Most standard media types are supported out-of-the-box, but you can also define new ones:
+
+[source,yaml,indent=0,subs="verbatim,quotes,attributes",configblocks]
+----
+	spring:
+	  mvc:
+	    contentnegotiation:
+	      media-types:
+	        markdown: "text/markdown"
+----
+
+
+
 Suffix pattern matching is deprecated and will be removed in a future release.
 If you understand the caveats and would still like your application to use suffix pattern matching, the following configuration is required:
 
@@ -2611,22 +2694,26 @@ If you understand the caveats and would still like your application to use suffi
 
 Alternatively, rather than open all suffix patterns, it's more secure to only support registered suffix patterns:
 
-[source,properties,indent=0,subs="verbatim,quotes,attributes"]
+[source,yaml,indent=0,subs="verbatim,quotes,attributes",configprops,configblocks]
 ----
-	spring.mvc.contentnegotiation.favor-path-extension=true
-	spring.mvc.pathmatch.use-registered-suffix-pattern=true
-
-	# You can also register additional file extensions/media types with:
-	# spring.mvc.contentnegotiation.media-types.adoc=text/asciidoc
+	spring:
+	  mvc:
+	    contentnegotiation:
+	      favor-path-extension: true
+	    pathmatch:
+	      use-registered-suffix-pattern: true
 ----
 
 As of Spring Framework 5.3, Spring MVC supports several implementation strategies for matching request paths to Controller handlers.
 It was previously only supporting the `AntPathMatcher` strategy, but it now also offers `PathPatternParser`.
 Spring Boot now provides a configuration property to choose and opt in the new strategy:
 
-[source,properties,indent=0,subs="verbatim,quotes,attributes"]
+[source,yaml,indent=0,subs="verbatim,quotes,attributes",configprops,configblocks]
 ----
-	spring.mvc.pathmatch.matching-strategy=path_pattern_parser
+	spring:
+	  mvc:
+	    pathmatch:
+	      matching-strategy: "path-pattern-parser"
 ----
 
 For more details on why you should consider this new implementation, please check out the
@@ -2999,9 +3086,11 @@ It uses the `ResourceWebHandler` from Spring WebFlux so that you can modify that
 By default, resources are mapped on `+/**+`, but you can tune that by setting the configprop:spring.webflux.static-path-pattern[] property.
 For instance, relocating all resources to `/resources/**` can be achieved as follows:
 
-[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
+[source,yaml,indent=0,subs="verbatim,quotes,attributes",configprops,configblocks]
 ----
-	spring.webflux.static-path-pattern=/resources/**
+	spring:
+	  webflux:
+	    static-path-pattern: "/resources/**"
 ----
 
 You can also customize the static resource locations by using `spring.resources.static-locations`.
@@ -3264,7 +3353,7 @@ Most applications are auto-configured, and the appropriate `ApplicationContext`
 [[boot-features-customizing-embedded-containers]]
 ==== Customizing Embedded Servlet Containers
 Common servlet container settings can be configured by using Spring `Environment` properties.
-Usually, you would define the properties in your `application.properties` file.
+Usually, you would define the properties in your `application.properties` or `application.yaml` file.
 
 Common server settings include:
 
@@ -3382,16 +3471,19 @@ NOTE: Graceful shutdown with Tomcat requires Tomcat 9.0.33 or later.
 
 To enable graceful shutdown, configure the configprop:server.shutdown[] property, as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-server.shutdown=graceful
+server:
+  shutdown: "graceful"
 ----
 
 To configure the timeout period, configure the configprop:spring.lifecycle.timeout-per-shutdown-phase[] property, as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-spring.lifecycle.timeout-per-shutdown-phase=20s
+spring:
+  lifecycle:
+    timeout-per-shutdown-phase: "20s"
 ----
 
 IMPORTANT: Using graceful shutdown with your IDE may not work properly if it does not send a proper `SIGTERM` signal.
@@ -3434,11 +3526,13 @@ This depends on the type of application and its configuration.
 
 For WebFlux application (i.e. of type `WebApplicationType.REACTIVE`), the RSocket server will be plugged into the Web Server only if the following properties match:
 
-[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
+[source,yaml,indent=0,subs="verbatim,quotes,attributes",configprops,configblocks]
 ----
-	spring.rsocket.server.mapping-path=/rsocket # a mapping path is defined
-	spring.rsocket.server.transport=websocket # websocket is chosen as a transport
-	#spring.rsocket.server.port= # no port is defined
+	spring:
+	  rsocket:
+	    server:
+	      mapping-path: "/rsocket"
+	      transport: "websocket"
 ----
 
 WARNING: Plugging RSocket into a web server is only supported with Reactor Netty, as RSocket itself is built with that library.
@@ -3446,10 +3540,12 @@ WARNING: Plugging RSocket into a web server is only supported with Reactor Netty
 Alternatively, an RSocket TCP or websocket server is started as an independent, embedded server.
 Besides the dependency requirements, the only required configuration is to define a port for that server:
 
-[source,properties,indent=0,subs="verbatim,quotes,attributes",configprops]
+[source,yaml,indent=0,subs="verbatim,quotes,attributes",configprops,configblocks]
 ----
-	spring.rsocket.server.port=9898 # the only required configuration
-	spring.rsocket.server.transport=tcp # you're free to configure other properties
+	spring:
+	  rsocket:
+	    server:
+	      port: 9898
 ----
 
 
@@ -3580,32 +3676,41 @@ The same properties are applicable to both servlet and reactive applications.
 
 You can register multiple OAuth2 clients and providers under the `spring.security.oauth2.client` prefix, as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.security.oauth2.client.registration.my-client-1.client-id=abcd
-	spring.security.oauth2.client.registration.my-client-1.client-secret=password
-	spring.security.oauth2.client.registration.my-client-1.client-name=Client for user scope
-	spring.security.oauth2.client.registration.my-client-1.provider=my-oauth-provider
-	spring.security.oauth2.client.registration.my-client-1.scope=user
-	spring.security.oauth2.client.registration.my-client-1.redirect-uri=https://my-redirect-uri.com
-	spring.security.oauth2.client.registration.my-client-1.client-authentication-method=basic
-	spring.security.oauth2.client.registration.my-client-1.authorization-grant-type=authorization_code
+	spring:
+	  security:
+	    oauth2:
+	      client:
+	        registration:
+	          my-client-1:
+	            client-id: "abcd"
+	            client-secret: "password"
+	            client-name: "Client for user scope"
+	            provider: "my-oauth-provider"
+	            scope: "user"
+	            redirect-uri: "https://my-redirect-uri.com"
+	            client-authentication-method: "basic"
+	            authorization-grant-type: "authorization-code"
 
-	spring.security.oauth2.client.registration.my-client-2.client-id=abcd
-	spring.security.oauth2.client.registration.my-client-2.client-secret=password
-	spring.security.oauth2.client.registration.my-client-2.client-name=Client for email scope
-	spring.security.oauth2.client.registration.my-client-2.provider=my-oauth-provider
-	spring.security.oauth2.client.registration.my-client-2.scope=email
-	spring.security.oauth2.client.registration.my-client-2.redirect-uri=https://my-redirect-uri.com
-	spring.security.oauth2.client.registration.my-client-2.client-authentication-method=basic
-	spring.security.oauth2.client.registration.my-client-2.authorization-grant-type=authorization_code
+	          my-client-2:
+	            client-id: "abcd"
+	            client-secret: "password"
+	            client-name: "Client for email scope"
+	            provider: "my-oauth-provider"
+	            scope: "email"
+	            redirect-uri: "https://my-redirect-uri.com"
+	            client-authentication-method: "basic"
+	            authorization-grant-type: "authorization_code"
 
-	spring.security.oauth2.client.provider.my-oauth-provider.authorization-uri=https://my-auth-server/oauth/authorize
-	spring.security.oauth2.client.provider.my-oauth-provider.token-uri=https://my-auth-server/oauth/token
-	spring.security.oauth2.client.provider.my-oauth-provider.user-info-uri=https://my-auth-server/userinfo
-	spring.security.oauth2.client.provider.my-oauth-provider.user-info-authentication-method=header
-	spring.security.oauth2.client.provider.my-oauth-provider.jwk-set-uri=https://my-auth-server/token_keys
-	spring.security.oauth2.client.provider.my-oauth-provider.user-name-attribute=name
+	        provider:
+	          my-oauth-provider:
+	            authorization-uri: "https://my-auth-server/oauth/authorize"
+	            token-uri: "https://my-auth-server/oauth/token"
+	            user-info-uri: "https://my-auth-server/userinfo"
+	            user-info-authentication-method: "header"
+	            jwk-set-uri: "https://my-auth-server/token_keys"
+	            user-name-attribute: "name"
 ----
 
 For OpenID Connect providers that support https://openid.net/specs/openid-connect-discovery-1_0.html[OpenID Connect discovery], the configuration can be further simplified.
@@ -3614,9 +3719,15 @@ For example, if the `issuer-uri` provided is "https://example.com", then an `Ope
 The result is expected to be an `OpenID Provider Configuration Response`.
 The following example shows how an OpenID Connect Provider can be configured with the `issuer-uri`:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.security.oauth2.client.provider.oidc-provider.issuer-uri=https://dev-123456.oktapreview.com/oauth2/default/
+	spring:
+	  security:
+	    oauth2:
+	      client:
+	        provider:
+	          oidc-provider:
+	            issuer-uri: "https://dev-123456.oktapreview.com/oauth2/default/"
 ----
 
 By default, Spring Security's `OAuth2LoginAuthenticationFilter` only processes URLs matching `/login/oauth2/code/*`.
@@ -3651,14 +3762,20 @@ Also, if the key for the client registration matches a default supported provide
 
 In other words, the two configurations in the following example use the Google provider:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.security.oauth2.client.registration.my-client.client-id=abcd
-	spring.security.oauth2.client.registration.my-client.client-secret=password
-	spring.security.oauth2.client.registration.my-client.provider=google
-
-	spring.security.oauth2.client.registration.google.client-id=abcd
-	spring.security.oauth2.client.registration.google.client-secret=password
+	spring:
+	  security:
+	    oauth2:
+	      client:
+	        registration:
+	          my-client:
+	            client-id: "abcd"
+	            client-secret: "password"
+	            provider: "google"
+	          google:
+	            client-id: "abcd"
+	            client-secret: "password"
 ----
 
 
@@ -3668,14 +3785,24 @@ In other words, the two configurations in the following example use the Google p
 If you have `spring-security-oauth2-resource-server` on your classpath, Spring Boot can set up an OAuth2 Resource Server.
 For JWT configuration, a JWK Set URI or OIDC Issuer URI needs to be specified, as shown in the following examples:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.security.oauth2.resourceserver.jwt.jwk-set-uri=https://example.com/oauth2/default/v1/keys
+	spring:
+	  security:
+	    oauth2:
+	      resourceserver:
+	        jwt:
+	          jwk-set-uri: "https://example.com/oauth2/default/v1/keys"
 ----
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.security.oauth2.resourceserver.jwt.issuer-uri=https://dev-123456.oktapreview.com/oauth2/default/
+	spring:
+	  security:
+	    oauth2:
+	      resourceserver:
+	        jwt:
+	          issuer-uri: "https://dev-123456.oktapreview.com/oauth2/default/"
 ----
 
 NOTE: If the authorization server does not support a JWK Set URI, you can configure the resource server with the Public Key used for verifying the signature of the JWT.
@@ -3687,11 +3814,16 @@ Alternatively, you can define your own `JwtDecoder` bean for servlet application
 
 In cases where opaque tokens are used instead of JWTs, you can configure the following properties to validate tokens via introspection:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.security.oauth2.resourceserver.opaquetoken.introspection-uri=https://example.com/check-token
-	spring.security.oauth2.resourceserver.opaquetoken.client-id=my-client-id
-	spring.security.oauth2.resourceserver.opaquetoken.client-secret=my-client-secret
+	spring:
+	  security:
+	    oauth2:
+	      resourceserver:
+	        opaquetoken:
+	          introspection-uri: "https://example.com/check-token"
+	          client-id: "my-client-id"
+	          client-secret: "my-client-secret"
 ----
 
 Again, the same properties are applicable for both servlet and reactive applications.
@@ -3719,19 +3851,35 @@ This configuration makes use of the properties under `Saml2RelyingPartyPropertie
 A relying party registration represents a paired configuration between an Identity Provider, IDP, and a Service Provider, SP.
 You can register multiple relying parties under the `spring.security.saml2.relyingparty` prefix, as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.security.saml2.relyingparty.registration.my-relying-party1.signing.credentials[0].private-key-location=path-to-private-key
-	spring.security.saml2.relyingparty.registration.my-relying-party1.signing.credentials[0].certificate-location=path-to-certificate
-	spring.security.saml2.relyingparty.registration.my-relying-party1.identityprovider.verification.credentials[0].certificate-location=path-to-verification-cert
-	spring.security.saml2.relyingparty.registration.my-relying-party1.identityprovider.entity-id=remote-idp-entity-id1
-	spring.security.saml2.relyingparty.registration.my-relying-party1.identityprovider.sso-url=https://remoteidp1.sso.url
+	spring:
+	  security:
+	    saml2:
+	      relyingparty:
+	        registration:
+	          my-relying-party1:
+	            signing.credentials:
+                - private-key-location: "path-to-private-key"
+	              certificate-location: "path-to-certificate"
+	            identityprovider:
+	              verification:
+	                credentials:
+	                - certificate-location: "path-to-verification-cert"
+	              entity-id: "remote-idp-entity-id1"
+	              sso-url: "https://remoteidp1.sso.url"
 
-	spring.security.saml2.relyingparty.registration.my-relying-party2.signing.credentials[0].private-key-location=path-to-private-key
-    spring.security.saml2.relyingparty.registration.my-relying-party2.signing.credentials[0].certificate-location=path-to-certificate
-    spring.security.saml2.relyingparty.registration.my-relying-party2.identityprovider.verification.credentials[0].certificate-location=path-to-other-verification-cert
-    spring.security.saml2.relyingparty.registration.my-relying-party2.identityprovider.entity-id=remote-idp-entity-id2
-    spring.security.saml2.relyingparty.registration.my-relying-party2.identityprovider.sso-url=https://remoteidp2.sso.url
+	          my-relying-party2:
+	            signing:
+	              credentials:
+	              - private-key-location: "path-to-private-key"
+                    certificate-location: "path-to-certificate"
+                identityprovider:
+                  verification:
+                    credentials:
+                    - certificate-location: "path-to-other-verification-cert"
+                  entity-id: "remote-idp-entity-id2"
+                  sso-url: "https://remoteidp2.sso.url"
 ----
 
 
@@ -3840,18 +3988,21 @@ If you define your own `DataSource` bean, auto-configuration does not occur.
 DataSource configuration is controlled by external configuration properties in `+spring.datasource.*+`.
 For example, you might declare the following section in `application.properties`:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.datasource.url=jdbc:mysql://localhost/test
-	spring.datasource.username=dbuser
-	spring.datasource.password=dbpass
-	spring.datasource.driver-class-name=com.mysql.jdbc.Driver
+	spring:
+	  datasource:
+	    url: "jdbc:mysql://localhost/test"
+	    username: "dbuser"
+	    password: "dbpass"
 ----
 
 NOTE: You should at least specify the URL by setting the configprop:spring.datasource.url[] property.
 Otherwise, Spring Boot tries to auto-configure an embedded database.
 
-TIP: You often do not need to specify the `driver-class-name`, since Spring Boot can deduce it for most databases from the `url`.
+TIP: Spring Boot can deduce the JDBC driver class for most databases from the URL.
+If you need to specify a specific class, you can use the configprop:spring.datasource.driver-class-name[] property.
+
 
 NOTE: For a pooling `DataSource` to be created, we need to be able to verify that a valid `Driver` class is available, so we check for that before doing anything.
 In other words, if you set `spring.datasource.driver-class-name=com.mysql.jdbc.Driver`, then that class has to be loadable.
@@ -3863,18 +4014,18 @@ Refer to the documentation of the connection pool implementation you are using f
 
 For instance, if you use the {tomcat-docs}/jdbc-pool.html#Common_Attributes[Tomcat connection pool], you could customize many additional settings, as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	# Number of ms to wait before throwing an exception if no connection is available.
-	spring.datasource.tomcat.max-wait=10000
-
-	# Maximum number of active connections that can be allocated from this pool at the same time.
-	spring.datasource.tomcat.max-active=50
-
-	# Validate the connection before borrowing it from the pool.
-	spring.datasource.tomcat.test-on-borrow=true
+	spring:
+	  datasource:
+	    tomcat:
+	      max-wait: 10000
+	      max-active: 50
+	      test-on-borrow: true
 ----
 
+This will set the pool to wait 10000 ms before throwing an exception if no connection is available, limit the maximum number of connections to 50 and validate the connection before borrowing it from the pool.
+
 
 
 [[boot-features-connecting-to-a-jndi-datasource]]
@@ -3884,9 +4035,11 @@ If you deploy your Spring Boot application to an Application Server, you might w
 The configprop:spring.datasource.jndi-name[] property can be used as an alternative to the configprop:spring.datasource.url[], configprop:spring.datasource.username[], and configprop:spring.datasource.password[] properties to access the `DataSource` from a specific JNDI location.
 For example, the following section in `application.properties` shows how you can access a JBoss AS defined `DataSource`:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.datasource.jndi-name=java:jboss/datasources/customers
+	spring:
+	  datasource:
+	    jndi-name: "java:jboss/datasources/customers"
 ----
 
 
@@ -3918,9 +4071,12 @@ Spring's `JdbcTemplate` and `NamedParameterJdbcTemplate` classes are auto-config
 
 You can customize some properties of the template by using the `spring.jdbc.template.*` properties, as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.jdbc.template.max-rows=500
+	spring:
+	  jdbc:
+	    template:
+	      max-rows: 500
 ----
 
 NOTE: The `NamedParameterJdbcTemplate` reuses the same `JdbcTemplate` instance behind the scenes.
@@ -4224,11 +4380,13 @@ Connections are provided via a `ConnectionFactory`, similar to a `DataSource` wi
 `ConnectionFactory` configuration is controlled by external configuration properties in `+spring.r2dbc.*+`.
 For example, you might declare the following section in `application.properties`:
 
-[source,properties,indent=0]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.r2dbc.url=r2dbc:postgresql://localhost/test
-	spring.r2dbc.username=dbuser
-	spring.r2dbc.password=dbpass
+	spring:
+	  r2dbc:
+	    url: "r2dbc:postgresql://localhost/test"
+	    username: "dbuser"
+	    password: "dbpass"
 ----
 
 TIP: You do not need to specify a driver class name, since Spring Boot obtains the driver from R2DBC's Connection Factory discovery.
@@ -4469,13 +4627,16 @@ You can set the configprop:spring.data.mongodb.uri[] property to change the URL
 Alternatively, you can specify connection details using discrete properties.
 For example, you might declare the following settings in your `application.properties`:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.data.mongodb.host=mongoserver.example.com
-	spring.data.mongodb.port=27017
-	spring.data.mongodb.database=test
-	spring.data.mongodb.username=user
-	spring.data.mongodb.password=secret
+	spring:
+	  data:
+	    mongodb:
+	      host: "mongoserver.example.com"
+	      port: 27017
+	      database: "test"
+	      username: "user"
+	      password: "secret"
 ----
 
 TIP: If `spring.data.mongodb.port` is not specified, the default of `27017` is used.
@@ -4599,11 +4760,14 @@ The following example shows how to inject a Neo4j `Driver` that gives you access
 You can configure various aspects of the driver using `spring.neo4j.*` properties.
 The following example shows how to configure the uri and credentials to use:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.neo4j.uri=bolt://my-server:7687
-	spring.neo4j.authentication.username=neo4j
-	spring.neo4j.authentication.password=secret
+	spring:
+	  neo4j:
+	    uri: "bolt://my-server:7687"
+	    authentication:
+	      username: "neo4j"
+	      password: "secret"
 ----
 
 The auto-configured `Driver` is created using `ConfigBuilder`.
@@ -4703,6 +4867,7 @@ Spring Boot supports several clients:
 Spring Boot provides a dedicated "`Starter`", `spring-boot-starter-data-elasticsearch`.
 
 
+
 [[boot-features-connecting-to-elasticsearch-rest]]
 ==== Connecting to Elasticsearch using REST clients
 Elasticsearch ships https://www.elastic.co/guide/en/elasticsearch/client/java-rest/current/index.html[two different REST clients] that you can use to query a cluster: the "Low Level" client and the "High Level" client.
@@ -4711,12 +4876,15 @@ Spring Boot provides support for the "High Level" client, which ships with `org.
 If you have this dependency on the classpath, Spring Boot will auto-configure and register a `RestHighLevelClient` bean that by default targets `http://localhost:9200`.
 You can further tune how `RestHighLevelClient` is configured, as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.elasticsearch.rest.uris=https://search.example.com:9200
-	spring.elasticsearch.rest.read-timeout=10s
-	spring.elasticsearch.rest.username=user
-	spring.elasticsearch.rest.password=secret
+	spring:
+	  elasticsearch:
+	    rest:
+	      uris: "https://search.example.com:9200"
+	      read-timeout: "10s"
+	      username: "user"
+	      password: "secret"
 ----
 
 You can also register an arbitrary number of beans that implement `RestClientBuilderCustomizer` for more advanced customizations.
@@ -4724,6 +4892,8 @@ To take full control over the registration, define a `RestClientBuilder` bean.
 
 TIP: If your application needs access to a "Low Level" `RestClient`, you can get it by calling `client.getLowLevelClient()` on the auto-configured `RestHighLevelClient`.
 
+
+
 [[boot-features-connecting-to-elasticsearch-reactive-rest]]
 ==== Connecting to Elasticsearch using Reactive REST clients
 {spring-data-elasticsearch}[Spring Data Elasticsearch] ships `ReactiveElasticsearchClient` for querying Elasticsearch instances in a reactive fashion.
@@ -4733,18 +4903,25 @@ By default, Spring Boot will auto-configure and register a `ReactiveElasticsearc
 bean that targets `http://localhost:9200`.
 You can further tune how it is configured, as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.data.elasticsearch.client.reactive.endpoints=search.example.com:9200
-	spring.data.elasticsearch.client.reactive.use-ssl=true
-	spring.data.elasticsearch.client.reactive.socket-timeout=10s
-	spring.data.elasticsearch.client.reactive.username=user
-	spring.data.elasticsearch.client.reactive.password=secret
+	spring:
+	  data:
+	    elasticsearch:
+	      client:
+	        reactive:
+	          endpoints: "search.example.com:9200"
+	          use-ssl: true
+	          socket-timeout: "10s"
+	          username: "user"
+	          password: "secret"
 ----
 
 If the configuration properties are not enough and you'd like to fully control the client
 configuration, you can register a custom `ClientConfiguration` bean.
 
+
+
 [[boot-features-connecting-to-elasticsearch-spring-data]]
 ==== Connecting to Elasticsearch by Using Spring Data
 To connect to Elasticsearch, a `RestHighLevelClient` bean must be defined,
@@ -4792,9 +4969,13 @@ Same applies to `ReactiveElasticsearchTemplate` and `ReactiveElasticsearchOperat
 
 You can choose to disable the repositories support with the following property:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-    spring.data.elasticsearch.repositories.enabled=false
+    spring:
+      data:
+        elasticsearch:
+          repositories:
+            enabled: false
 ----
 
 
@@ -4812,20 +4993,26 @@ You can inject an auto-configured `CassandraTemplate` or a Cassandra `CqlSession
 The `spring.data.cassandra.*` properties can be used to customize the connection.
 Generally, you provide `keyspace-name` and `contact-points` as well the local datacenter name, as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.data.cassandra.keyspace-name=mykeyspace
-	spring.data.cassandra.contact-points=cassandrahost1:9042,cassandrahost2:9042
-	spring.data.cassandra.local-datacenter=datacenter1
+	spring:
+	  data:
+	    cassandra:
+	      keyspace-name: "mykeyspace"
+	      contact-points: "cassandrahost1:9042,cassandrahost2:9042"
+	      local-datacenter: "datacenter1"
 ----
 
 If the port is the same for all your contact points you can use a shortcut and only specify the host names, as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.data.cassandra.keyspace-name=mykeyspace
-	spring.data.cassandra.contact-points=cassandrahost1,cassandrahost2
-	spring.data.cassandra.local-datacenter=datacenter1
+	spring:
+	  data:
+	    cassandra:
+	      keyspace-name: "mykeyspace"
+	      contact-points: "cassandrahost1,cassandrahost2"
+	      local-datacenter: "datacenter1"
 ----
 
 TIP: Those two examples are identical as the port default to `9042`.
@@ -4887,21 +5074,28 @@ You can get a `Cluster` by adding the Couchbase SDK and some configuration.
 The `spring.couchbase.*` properties can be used to customize the connection.
 Generally, you provide the https://github.com/couchbaselabs/sdk-rfcs/blob/master/rfc/0011-connection-string.md[connection string], username, and password, as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.couchbase.connection-string=couchbase://192.168.1.123
-	spring.couchbase.username=user
-	spring.couchbase.password=secret
+	spring:
+	  couchbase:
+	    connection-string: "couchbase://192.168.1.123"
+	    username: "user"
+	    password: "secret"
 ----
 
 It is also possible to customize some of the `ClusterEnvironment` settings.
 For instance, the following configuration changes the timeout to use to open a new `Bucket` and enables SSL support:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.couchbase.env.timeouts.connect=3000
-	spring.couchbase.env.ssl.key-store=/location/of/keystore.jks
-	spring.couchbase.env.ssl.key-store-password=secret
+	spring:
+	  couchbase:
+	    env:
+	      timeouts:
+	        connect: "3s"
+	      ssl:
+	        key-store: "/location/of/keystore.jks"
+	        key-store-password: "secret"
 ----
 
 TIP: Check the `spring.couchbase.env.*` properties for more details.
@@ -4917,9 +5111,12 @@ For complete details of Spring Data Couchbase, refer to the {spring-data-couchba
 You can inject an auto-configured `CouchbaseTemplate` instance as you would with any other Spring Bean, provided a `CouchbaseClientFactory` bean is available.
 This happens when a `Cluster` is available, as described above, and a bucket name has been specified:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.data.couchbase.bucket-name=my-bucket
+	spring:
+	  data:
+	    couchbase:
+	      bucket-name: "my-bucket"
 ----
 
 The following examples shows how to inject a `CouchbaseTemplate` bean:
@@ -4981,11 +5178,13 @@ There is a `spring-boot-starter-data-ldap` "`Starter`" for collecting the depend
 ==== Connecting to an LDAP Server
 To connect to an LDAP server, make sure you declare a dependency on the `spring-boot-starter-data-ldap` "`Starter`" or `spring-ldap-core` and then declare the URLs of your server in your application.properties, as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.ldap.urls=ldap://myserver:1235
-	spring.ldap.username=admin
-	spring.ldap.password=secret
+	spring:
+	  ldap:
+	    urls: "ldap://myserver:1235"
+	    username: "admin"
+	    password: "secret"
 ----
 
 If you need to customize connection settings, you can use the `spring.ldap.base` and `spring.ldap.base-environment` properties.
@@ -5029,32 +5228,26 @@ You can also inject an auto-configured `LdapTemplate` instance as you would with
 For testing purposes, Spring Boot supports auto-configuration of an in-memory LDAP server from https://ldap.com/unboundid-ldap-sdk-for-java/[UnboundID].
 To configure the server, add a dependency to `com.unboundid:unboundid-ldapsdk` and declare a configprop:spring.ldap.embedded.base-dn[] property, as follows:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.ldap.embedded.base-dn=dc=spring,dc=io
+	spring:
+	  ldap:
+	    embedded:
+	      base-dn: "dc=spring,dc=io"
 ----
 
 [NOTE]
 ====
 It is possible to define multiple base-dn values, however, since distinguished names usually contain commas, they must be defined using the correct notation.
 
-In yaml files, you can use the yaml list notation:
+In yaml files, you can use the yaml list notation. In properties files, you must include the index as part of the property name:
 
-[source,yaml,indent=0]
+[source,yaml,indent=0,configprops,configblocks]
 ----
 	spring.ldap.embedded.base-dn:
 	  - dc=spring,dc=io
 	  - dc=pivotal,dc=io
 ----
-
-In properties files, you must include the index as part of the property name:
-
-[source,properties,indent=0,configprops]
-----
-	spring.ldap.embedded.base-dn[0]=dc=spring,dc=io
-	spring.ldap.embedded.base-dn[1]=dc=pivotal,dc=io
-----
-
 ====
 
 By default, the server starts on a random port and triggers the regular LDAP support.
@@ -5079,9 +5272,11 @@ https://www.influxdata.com/[InfluxDB] is an open-source time series database opt
 ==== Connecting to InfluxDB
 Spring Boot auto-configures an `InfluxDB` instance, provided the `influxdb-java` client is on the classpath and the URL of the database is set, as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.influx.url=https://172.0.0.1:8086
+	spring:
+	  influx:
+	    url: "https://172.0.0.1:8086"
 ----
 
 If the connection to InfluxDB requires a user and password, you can set the `spring.influx.user` and `spring.influx.password` properties accordingly.
@@ -5168,10 +5363,12 @@ The following example sets a flag to say that `null` values should be passed dow
 	@Bean
 	public CacheManagerCustomizer<ConcurrentMapCacheManager> cacheManagerCustomizer() {
 		return new CacheManagerCustomizer<ConcurrentMapCacheManager>() {
+
 			@Override
 			public void customize(ConcurrentMapCacheManager cacheManager) {
 				cacheManager.setAllowNullValues(false);
 			}
+
 		};
 	}
 ----
@@ -5198,11 +5395,14 @@ Any other compliant library can be added as well.
 It might happen that more than one provider is present, in which case the provider must be explicitly specified.
 Even if the JSR-107 standard does not enforce a standardized way to define the location of the configuration file, Spring Boot does its best to accommodate setting a cache with implementation details, as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
     # Only necessary if more than one provider is present
-	spring.cache.jcache.provider=com.acme.MyCachingProvider
-	spring.cache.jcache.config=classpath:acme.xml
+	spring:
+	  cache:
+	    jcache:
+	      provider: "com.acme.MyCachingProvider"
+	      config: "classpath:acme.xml"
 ----
 
 NOTE: When a cache library offers both a native implementation and JSR-107 support, Spring Boot prefers the JSR-107 support, so that the same features are available if you switch to a different JSR-107 implementation.
@@ -5227,9 +5427,12 @@ https://www.ehcache.org/[EhCache] 2.x is used if a file named `ehcache.xml` can
 If EhCache 2.x is found, the `EhCacheCacheManager` provided by the `spring-boot-starter-cache` "`Starter`" is used to bootstrap the cache manager.
 An alternate configuration file can be provided as well, as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.cache.ehcache.config=classpath:config/another-config.xml
+	spring:
+	  cache:
+	    ehcache:
+	      config: "classpath:config/another-config.xml"
 ----
 
 
@@ -5246,9 +5449,12 @@ If a `HazelcastInstance` has been auto-configured, it is automatically wrapped i
 https://infinispan.org/[Infinispan] has no default configuration file location, so it must be specified explicitly.
 Otherwise, the default bootstrap is used.
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.cache.infinispan.config=infinispan.xml
+	spring:
+	  cache:
+	    infinispan:
+	      config: "infinispan.xml"
 ----
 
 Caches can be created on startup by setting the configprop:spring.cache.cache-names[] property.
@@ -5266,10 +5472,13 @@ If Spring Data Couchbase is available and Couchbase is <<boot-features-couchbase
 It is possible to create additional caches on startup by setting the configprop:spring.cache.cache-names[] property and cache defaults can be configured by using `spring.cache.couchbase.*` properties.
 For instance, the following configuration creates `cache1` and `cache2` caches with an entry _expiration_ of 10 minutes:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.cache.cache-names=cache1,cache2
-    spring.cache.couchbase.expiration=10m
+	spring:
+	  cache:
+	    cache-names: "cache1,cache2"
+        couchbase:
+          expiration: "10m"
 ----
 
 If you need more control over the configuration, consider registering a `CouchbaseCacheManagerBuilderCustomizer` bean.
@@ -5288,10 +5497,13 @@ If https://redis.io/[Redis] is available and configured, a `RedisCacheManager` i
 It is possible to create additional caches on startup by setting the configprop:spring.cache.cache-names[] property and cache defaults can be configured by using `spring.cache.redis.*` properties.
 For instance, the following configuration creates `cache1` and `cache2` caches with a _time to live_ of 10 minutes:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.cache.cache-names=cache1,cache2
-	spring.cache.redis.time-to-live=600000
+	spring:
+	  cache:
+	    cache-names: "cache1,cache2"
+	    redis:
+	      time-to-live: "10m"
 ----
 
 NOTE: By default, a key prefix is added so that, if two separate caches use the same key, Redis does not have overlapping keys and cannot return invalid values.
@@ -5323,10 +5535,13 @@ Caches can be created on startup by setting the configprop:spring.cache.cache-na
 
 For instance, the following configuration creates `cache1` and `cache2` caches with a maximum size of 500 and a _time to live_ of 10 minutes
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.cache.cache-names=cache1,cache2
-	spring.cache.caffeine.spec=maximumSize=500,expireAfterAccess=600s
+	spring:
+	  cache:
+	    cache-names: "cache1,cache2"
+	    caffeine:
+	      spec: "maximumSize=500,expireAfterAccess=600s"
 ----
 
 If a `com.github.benmanes.caffeine.cache.CacheLoader` bean is defined, it is automatically associated to the `CaffeineCacheManager`.
@@ -5342,9 +5557,11 @@ This is the default if no caching library is present in your application.
 By default, caches are created as needed, but you can restrict the list of available caches by setting the `cache-names` property.
 For instance, if you want only `cache1` and `cache2` caches, set the `cache-names` property as follows:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.cache.cache-names=cache1,cache2
+	spring:
+	  cache:
+	    cache-names: "cache1,cache2"
 ----
 
 If you do so and your application uses a cache not listed, then it fails at runtime when the cache is needed, but not on startup.
@@ -5357,9 +5574,11 @@ This is similar to the way the "real" cache providers behave if you use an undec
 When `@EnableCaching` is present in your configuration, a suitable cache configuration is expected as well.
 If you need to disable caching altogether in certain environments, force the cache type to `none` to use a no-op implementation, as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.cache.type=none
+	spring:
+	  cache:
+	    type: "none"
 ----
 
 
@@ -5393,26 +5612,34 @@ NOTE: If you use `spring-boot-starter-activemq`, the necessary dependencies to c
 ActiveMQ configuration is controlled by external configuration properties in `+spring.activemq.*+`.
 For example, you might declare the following section in `application.properties`:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.activemq.broker-url=tcp://192.168.1.210:9876
-	spring.activemq.user=admin
-	spring.activemq.password=secret
+	spring:
+	  activemq:
+	    broker-url: "tcp://192.168.1.210:9876"
+	    user: "admin"
+	    password: "secret"
 ----
 
 By default, a `CachingConnectionFactory` wraps the native `ConnectionFactory` with sensible settings that you can control by external configuration properties in `+spring.jms.*+`:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.jms.cache.session-cache-size=5
+	spring:
+	  jms:
+	    cache:
+	      session-cache-size: 5
 ----
 
 If you'd rather use native pooling, you can do so by adding a dependency to `org.messaginghub:pooled-jms` and configuring the `JmsPoolConnectionFactory` accordingly, as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.activemq.pool.enabled=true
-	spring.activemq.pool.max-connections=50
+	spring:
+	  activemq:
+	    pool:
+	      enabled: true
+	      max-connections: 50
 ----
 
 TIP: See {spring-boot-autoconfigure-module-code}/jms/activemq/ActiveMQProperties.java[`ActiveMQProperties`] for more of the supported options.
@@ -5435,13 +5662,15 @@ Adding `org.apache.activemq:artemis-jms-server` to your application lets you use
 Artemis configuration is controlled by external configuration properties in `+spring.artemis.*+`.
 For example, you might declare the following section in `application.properties`:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.artemis.mode=native
-	spring.artemis.host=192.168.1.210
-	spring.artemis.port=9876
-	spring.artemis.user=admin
-	spring.artemis.password=secret
+	spring:
+	  artemis:
+	    mode: native
+	    host: "192.168.1.210"
+	    port: 9876
+	    user: "admin"
+	    password: "secret"
 ----
 
 When embedding the broker, you can choose if you want to enable persistence and list the destinations that should be made available.
@@ -5449,17 +5678,23 @@ These can be specified as a comma-separated list to create them with the default
 
 By default, a `CachingConnectionFactory` wraps the native `ConnectionFactory` with sensible settings that you can control by external configuration properties in `+spring.jms.*+`:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.jms.cache.session-cache-size=5
+	spring:
+	  jms:
+	    cache:
+	      session-cache-size: 5
 ----
 
 If you'd rather use native pooling, you can do so by adding a dependency to `org.messaginghub:pooled-jms` and configuring the `JmsPoolConnectionFactory` accordingly, as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.artemis.pool.enabled=true
-	spring.artemis.pool.max-connections=50
+	spring:
+	  artemis:
+	    pool:
+	      enabled: true
+	      max-connections: 50
 ----
 
 See {spring-boot-autoconfigure-module-code}/jms/artemis/ArtemisProperties.java[`ArtemisProperties`] for more supported options.
@@ -5474,9 +5709,11 @@ If you are running your application in an application server, Spring Boot tries
 By default, the `java:/JmsXA` and `java:/XAConnectionFactory` location are checked.
 You can use the configprop:spring.jms.jndi-name[] property if you need to specify an alternative location, as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.jms.jndi-name=java:/MyConnectionFactory
+	spring:
+	  jms:
+	    jndi-name: "java:/MyConnectionFactory"
 ----
 
 
@@ -5597,19 +5834,23 @@ Spring uses `RabbitMQ` to communicate through the AMQP protocol.
 RabbitMQ configuration is controlled by external configuration properties in `+spring.rabbitmq.*+`.
 For example, you might declare the following section in `application.properties`:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.rabbitmq.host=localhost
-	spring.rabbitmq.port=5672
-	spring.rabbitmq.username=admin
-	spring.rabbitmq.password=secret
+	spring:
+	  rabbitmq:
+	    host: "localhost"
+	    port: 5672
+	    username: "admin"
+	    password: "secret"
 ----
 
 Alternatively, you could configure the same connection using the `addresses` attribute:
 
-[source,properties,indent=0]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.rabbitmq.addresses=amqp://admin:secret@localhost
+	spring:
+	  rabbitmq:
+	    addresses: "amqp://admin:secret@localhost"
 ----
 
 NOTE: When specifying addresses that way, the `host` and `port` properties are ignored.
@@ -5657,10 +5898,14 @@ If necessary, any `org.springframework.amqp.core.Queue` that is defined as a bea
 
 To retry operations, you can enable retries on the `AmqpTemplate` (for example, in the event that the broker connection is lost):
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.rabbitmq.template.retry.enabled=true
-	spring.rabbitmq.template.retry.initial-interval=2s
+	spring:
+	  rabbitmq:
+	    template:
+	      retry:
+	        enabled: true
+	        initial-interval: "2s"
 ----
 
 Retries are disabled by default.
@@ -5753,10 +5998,13 @@ https://kafka.apache.org/[Apache Kafka] is supported by providing auto-configura
 Kafka configuration is controlled by external configuration properties in `spring.kafka.*`.
 For example, you might declare the following section in `application.properties`:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.kafka.bootstrap-servers=localhost:9092
-	spring.kafka.consumer.group-id=myGroup
+	spring:
+	  kafka:
+	    bootstrap-servers: "localhost:9092"
+	    consumer:
+	      group-id: "myGroup"
 ----
 
 TIP: To create a topic on startup, add a bean of type `NewTopic`.
@@ -5859,32 +6107,51 @@ Spring Boot auto-configuration supports all HIGH importance properties, some sel
 Only a subset of the properties supported by Kafka are available directly through the `KafkaProperties` class.
 If you wish to configure the producer or consumer with additional properties that are not directly supported, use the following properties:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.kafka.properties.prop.one=first
-	spring.kafka.admin.properties.prop.two=second
-	spring.kafka.consumer.properties.prop.three=third
-	spring.kafka.producer.properties.prop.four=fourth
-	spring.kafka.streams.properties.prop.five=fifth
+	spring:
+	  kafka:
+	    properties:
+	      "[prop.one]": "first"
+	    admin:
+	      properties:
+	        "[prop.two]": "second"
+	    consumer:
+	      properties:
+	        "[prop.three]": "third"
+	    producer:
+	      properties:
+	        "[prop.four]": "fourth"
+	    streams:
+	      properties:
+	        "[prop.five]": "fifth"
 ----
 
 This sets the common `prop.one` Kafka property to `first` (applies to producers, consumers and admins), the `prop.two` admin property to `second`, the `prop.three` consumer property to `third`, the `prop.four` producer property to `fourth` and the `prop.five` streams property to `fifth`.
 
 You can also configure the Spring Kafka `JsonDeserializer` as follows:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.kafka.consumer.value-deserializer=org.springframework.kafka.support.serializer.JsonDeserializer
-	spring.kafka.consumer.properties.spring.json.value.default.type=com.example.Invoice
-	spring.kafka.consumer.properties.spring.json.trusted.packages=com.example,org.acme
+	spring:
+	  kafka:
+	    consumer:
+	      value-deserializer: "org.springframework.kafka.support.serializer.JsonDeserializer"
+	      properties:
+	        "[spring.json.value.default.type]": "com.example.Invoice"
+	        "[spring.json.trusted.packages]": "com.example,org.acme"
 ----
 
 Similarly, you can disable the `JsonSerializer` default behavior of sending type information in headers:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.kafka.producer.value-serializer=org.springframework.kafka.support.serializer.JsonSerializer
-	spring.kafka.producer.properties.spring.json.add.type.headers=false
+	spring:
+	  kafka:
+	    producer:
+	      value-serializer: "org.springframework.kafka.support.serializer.JsonSerializer"
+	      properties:
+	        "[spring.json.add.type.headers]": false
 ----
 
 IMPORTANT: Properties set in this way override any configuration item that Spring Boot explicitly supports.
@@ -5904,24 +6171,26 @@ There are several ways to do that:
 
 [source,java,indent=0]
 ----
-static {
-    System.setProperty(EmbeddedKafkaBroker.BROKER_LIST_PROPERTY, "spring.kafka.bootstrap-servers");
-}
+	static {
+	    System.setProperty(EmbeddedKafkaBroker.BROKER_LIST_PROPERTY, "spring.kafka.bootstrap-servers");
+	}
 ----
 
 * Configure a property name on the `@EmbeddedKafka` annotation:
 
 [source,java,indent=0]
 ----
-@EmbeddedKafka(topics = "someTopic",
-        bootstrapServersProperty = "spring.kafka.bootstrap-servers")
+	@EmbeddedKafka(topics = "someTopic",
+	        bootstrapServersProperty = "spring.kafka.bootstrap-servers")
 ----
 
 * Use a placeholder in configuration properties:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-spring.kafka.bootstrap-servers=${spring.embedded.kafka.brokers}
+	spring:
+	  kafka:
+	    bootstrap-servers: "${spring.embedded.kafka.brokers}"
 ----
 
 
@@ -6089,18 +6358,23 @@ See {spring-boot-autoconfigure-module-code}/mail/MailProperties.java[`MailProper
 
 In particular, certain default timeout values are infinite, and you may want to change that to avoid having a thread blocked by an unresponsive mail server, as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.mail.properties.mail.smtp.connectiontimeout=5000
-	spring.mail.properties.mail.smtp.timeout=3000
-	spring.mail.properties.mail.smtp.writetimeout=5000
+	spring:
+	  mail:
+	    properties:
+	      "[mail.smtp.connectiontimeout]": 5000
+	      "[mail.smtp.timeout]": 3000
+	      "[mail.smtp.writetimeout]": 5000
 ----
 
 It is also possible to configure a `JavaMailSender` with an existing `Session` from JNDI:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.mail.jndi-name=mail/Session
+	spring:
+	  mail:
+	    jndi-name: "mail/Session"
 ----
 
 When a `jndi-name` is set, it takes precedence over all other Session-related settings.
@@ -6225,9 +6499,11 @@ If your configuration defines an instance name, Spring Boot tries to locate an e
 
 You could also specify the Hazelcast configuration file to use through configuration, as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.hazelcast.config=classpath:config/my-hazelcast.xml
+	spring:
+	  hazelcast:
+	    config: "classpath:config/my-hazelcast.xml"
 ----
 
 Otherwise, Spring Boot tries to find the Hazelcast configuration from the default locations: `hazelcast.xml` in the working directory or at the root of the classpath, or a `.yaml` counterpart in the same locations.
@@ -6254,16 +6530,21 @@ Beans of the following types are automatically picked up and associated with the
 By default, an in-memory `JobStore` is used.
 However, it is possible to configure a JDBC-based store if a `DataSource` bean is available in your application and if the configprop:spring.quartz.job-store-type[] property is configured accordingly, as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.quartz.job-store-type=jdbc
+	spring:
+	  quartz:
+	    job-store-type: "jdbc"
 ----
 
 When the JDBC store is used, the schema can be initialized on startup, as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.quartz.jdbc.initialize-schema=always
+	spring:
+	  quartz:
+	    jdbc:
+	      initialize-schema: "always"
 ----
 
 WARNING: By default, the database is detected and initialized by using the standard scripts provided with the Quartz library.
@@ -6325,11 +6606,15 @@ The auto-configured `TaskExecutorBuilder` allows you to easily create instances
 The thread pool uses 8 core threads that can grow and shrink according to the load.
 Those default settings can be fine-tuned using the `spring.task.execution` namespace as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.task.execution.pool.max-size=16
-	spring.task.execution.pool.queue-capacity=100
-	spring.task.execution.pool.keep-alive=10s
+	spring:
+	  task:
+	    execution:
+	      pool:
+	        max-size: 16
+	        queue-capacity: 100
+	        keep-alive: "10s"
 ----
 
 This changes the thread pool to use a bounded queue so that when the queue is full (100 tasks), the thread pool increases to maximum 16 threads.
@@ -6352,9 +6637,12 @@ Spring Boot also configures some features that are triggered by the presence of
 If `spring-integration-jmx` is also on the classpath, message processing statistics are published over JMX.
 If `spring-integration-jdbc` is available, the default database schema can be created on startup, as shown in the following line:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.integration.jdbc.initialize-schema=always
+	spring:
+	  integration:
+	    jdbc:
+	      initialize-schema: "always"
 ----
 
 If `spring-integration-rsocket` is available, developers can configure an RSocket server using `"spring.rsocket.server.*"` properties and let it use `IntegrationRSocketEndpoint` or `RSocketOutboundGateway` components to handle incoming RSocket messages.
@@ -6362,14 +6650,25 @@ This infrastructure can handle Spring Integration RSocket channel adapters and `
 
 Spring Boot can also auto-configure an `ClientRSocketConnector` using configuration properties:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
 	# Connecting to a RSocket server over TCP
-	spring.integration.rsocket.client.host=example.org
-	spring.integration.rsocket.client.port=9898
+	spring:
+	  integration:
+	    rsocket:
+	      client:
+	        host: "example.org"
+	        port: 9898
+----
 
+[source,yaml,indent=0,configprops,configblocks]
+----
 	# Connecting to a RSocket Server over WebSocket
-	spring.integration.rsocket.client.uri=ws://example.org
+	spring:
+	  integration:
+	    rsocket:
+	      client:
+	        uri: "ws://example.org"
 ----
 
 See the {spring-boot-autoconfigure-module-code}/integration/IntegrationAutoConfiguration.java[`IntegrationAutoConfiguration`] and {spring-boot-autoconfigure-module-code}/integration/IntegrationProperties.java[`IntegrationProperties`] classes for more details.
@@ -6398,9 +6697,11 @@ If a single Spring Session module is present on the classpath, Spring Boot uses
 If you have more than one implementation, you must choose the {spring-boot-autoconfigure-module-code}/session/StoreType.java[`StoreType`] that you wish to use to store the sessions.
 For instance, to use JDBC as the back-end store, you can configure your application as follows:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-    spring.session.store-type=jdbc
+    spring:
+      session:
+        store-type: "jdbc"
 ----
 
 TIP: You can disable Spring Session by setting the `store-type` to `none`.
@@ -6408,15 +6709,19 @@ TIP: You can disable Spring Session by setting the `store-type` to `none`.
 Each store has specific additional settings.
 For instance, it is possible to customize the name of the table for the JDBC store, as shown in the following example:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-    spring.session.jdbc.table-name=SESSIONS
+    spring:
+      session:
+        jdbc:
+          table-name: "SESSIONS"
 ----
 
 For setting the timeout of the session you can use the configprop:spring.session.timeout[] property.
 If that property is not set, the auto-configuration falls back to the value of configprop:server.servlet.session.timeout[].
 
 
+
 [[boot-features-jmx]]
 == Monitoring and Management over JMX
 Java Management Extensions (JMX) provide a standard mechanism to monitor and manage applications.
@@ -7798,9 +8103,11 @@ The {spring-webservices-docs}[Spring Web Services features] can be easily access
 To do so, configure their location, as shown in the following example:
 
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.webservices.wsdl-locations=classpath:/wsdl
+	spring:
+	  webservices:
+	    wsdl-locations: "classpath:/wsdl"
 ----
 
 
@@ -8443,19 +8750,19 @@ Out-of-the-box, the following layers are supported:
 
 The following shows an example of a `layers.idx` file:
 
-[source]
+[source,yaml,indent=0]
 ----
-- "dependencies":
-  - BOOT-INF/lib/library1.jar
-  - BOOT-INF/lib/library2.jar
-- "spring-boot-loader":
-  - org/springframework/boot/loader/JarLauncher.class
-  - org/springframework/boot/loader/jar/JarEntry.class
-- "snapshot-dependencies":
-  - BOOT-INF/lib/library3-SNAPSHOT.jar
-- "application":
-  - META-INF/MANIFEST.MF
-  - BOOT-INF/classes/a/b/C.class
+	- "dependencies":
+	  - BOOT-INF/lib/library1.jar
+	  - BOOT-INF/lib/library2.jar
+	- "spring-boot-loader":
+	  - org/springframework/boot/loader/JarLauncher.class
+	  - org/springframework/boot/loader/jar/JarEntry.class
+	- "snapshot-dependencies":
+	  - BOOT-INF/lib/library3-SNAPSHOT.jar
+	- "application":
+	  - META-INF/MANIFEST.MF
+	  - BOOT-INF/classes/a/b/C.class
 ----
 
 This layering is designed to separate code based on how likely it is to change between application builds.
diff --git a/spring-boot-project/spring-boot-docs/src/docs/asciidoc/using-spring-boot.adoc b/spring-boot-project/spring-boot-docs/src/docs/asciidoc/using-spring-boot.adoc
index 8bd5c61cd8..ce5d6ca8b8 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/asciidoc/using-spring-boot.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/asciidoc/using-spring-boot.adoc
@@ -630,9 +630,12 @@ The report shows the changes to your application's auto-configuration as you mak
 
 To disable the logging of the report, set the following property:
 
-[indent=0]
+[source,yaml,indent=0,configblocks]
 ----
-	spring.devtools.restart.log-condition-evaluation-delta=false
+	spring:
+	  devtools:
+	    restart:
+	      log-condition-evaluation-delta: false
 ----
 
 
@@ -644,9 +647,12 @@ By default, changing resources in `/META-INF/maven`, `/META-INF/resources`, `/re
 If you want to customize these exclusions, you can use the configprop:spring.devtools.restart.exclude[] property.
 For example, to exclude only `/static` and `/public` you would set the following property:
 
-[indent=0]
+[source,yaml,indent=0,configblocks]
 ----
-	spring.devtools.restart.exclude=static/**,public/**
+	spring:
+	  devtools:
+	    restart:
+	      exclude: "static/**,public/**"
 ----
 
 TIP: If you want to keep those defaults and _add_ additional exclusions, use the configprop:spring.devtools.restart.additional-exclude[] property instead.
@@ -700,9 +706,12 @@ For example, if you have a project with the following structure:
 
 Then your `trigger-file` property would be:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.devtools.restart.trigger-file=.reloadtrigger
+	spring:
+	  devtools:
+	    restart:
+	      trigger-file: ".reloadtrigger"
 ----
 
 Restarts will now only happen when the `src/main/resources/.reloadtrigger` is updated.
@@ -730,10 +739,13 @@ The `spring-devtools.properties` file can contain properties prefixed with `rest
 The `include` elements are items that should be pulled up into the "`restart`" classloader, and the `exclude` elements are items that should be pushed down into the "`base`" classloader.
 The value of the property is a regex pattern that is applied to the classpath, as shown in the following example:
 
-[source,properties,indent=0]
+[source,yaml,indent=0,configblocks]
 ----
-	restart.exclude.companycommonlibs=/mycorp-common-[\\w\\d-\.]+\.jar
-	restart.include.projectcommon=/mycorp-myproj-[\\w\\d-\.]+\.jar
+	restart:
+	  exclude:
+	    companycommonlibs: "/mycorp-common-[\\w\\d-\\.]+\\.jar"
+	  include:
+	    projectcommon: "/mycorp-myproj-[\\w\\d-\\.]+\\.jar"
 ----
 
 NOTE: All property keys must be unique.
@@ -776,12 +788,14 @@ You can configure global devtools settings by adding any of the following files
 . `spring-boot-devtools.yml`
 
 Any properties added to these file apply to _all_ Spring Boot applications on your machine that use devtools.
-For example, to configure restart to always use a <<using-boot-devtools-restart-triggerfile, trigger file>>, you would add the following property:
+For example, to configure restart to always use a <<using-boot-devtools-restart-triggerfile, trigger file>>, you would add the following property to your `spring-boot-devtools` file:
 
-.~/.config/spring-boot/spring-boot-devtools.properties
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.devtools.restart.trigger-file=.reloadtrigger
+	spring:
+	  devtools:
+	    restart:
+	      trigger-file: ".reloadtrigger"
 ----
 
 NOTE: If devtools configuration files are not found in `$HOME/.config/spring-boot`, the root of the `$HOME` directory is searched for the presence of a `.spring-boot-devtools.properties` file.
@@ -803,10 +817,13 @@ Profile specific filenames (of the form `spring-boot-devtools-<profile>.properti
 Since Spring Boot relies entirely on the IDE to compile and copy files into the location from where Spring Boot can read them, you might find that there are times when certain changes are not reflected when devtools restarts the application.
 If you observe such problems constantly, try increasing the `spring.devtools.restart.poll-interval` and `spring.devtools.restart.quiet-period` parameters to the values that fit your development environment:
 
-[source,properties,indent=0,configprops]
+[source,yaml,indent=0,configprops,configblocks]
 ----
-	spring.devtools.restart.poll-interval=2s
-	spring.devtools.restart.quiet-period=1s
+	spring:
+	  devtools:
+	    restart:
+	      poll-interval: "2s"
+	      quiet-period: "1s"
 ----
 
 The monitored classpath directories are now polled every 2 seconds for changes, and a 1 second quiet period is maintained to make sure there are no additional class changes.