Don't use monospacing in documentation headings
Closes gh-20875
This commit is contained in:
@@ -10,7 +10,7 @@ Remember to also look at the conditions report in your application for more deta
|
||||
|
||||
|
||||
[[auto-configuration-classes-from-autoconfigure-module]]
|
||||
== `spring-boot-autoconfigure`
|
||||
== spring-boot-autoconfigure
|
||||
The following auto-configuration classes are from the `spring-boot-autoconfigure` module:
|
||||
|
||||
include::auto-configuration-classes/spring-boot-autoconfigure.adoc[]
|
||||
@@ -18,7 +18,7 @@ include::auto-configuration-classes/spring-boot-autoconfigure.adoc[]
|
||||
|
||||
|
||||
[[auto-configuration-classes-from-actuator]]
|
||||
== `spring-boot-actuator-autoconfigure`
|
||||
== spring-boot-actuator-autoconfigure
|
||||
The following auto-configuration classes are from the `spring-boot-actuator-autoconfigure` module:
|
||||
|
||||
include::auto-configuration-classes/spring-boot-actuator-autoconfigure.adoc[]
|
||||
|
||||
@@ -231,7 +231,7 @@ The classpath is deduced from the nested jars.
|
||||
|
||||
|
||||
[[executable-jar-property-launcher-features]]
|
||||
== `PropertiesLauncher` Features
|
||||
== PropertiesLauncher Features
|
||||
`PropertiesLauncher` has a few special features that can be enabled with external properties (System properties, environment variables, manifest entries, or `loader.properties`).
|
||||
The following table describes these properties:
|
||||
|
||||
|
||||
@@ -68,7 +68,7 @@ Once the `spring-boot-antlib` namespace has been declared, the following additio
|
||||
|
||||
|
||||
[[spring-boot-ant-exejar]]
|
||||
==== `spring-boot:exejar`
|
||||
==== Using the "`exejar`" Task
|
||||
You can use the `exejar` task to create a Spring Boot executable jar.
|
||||
The following attributes are supported by the task:
|
||||
|
||||
@@ -136,7 +136,7 @@ This section shows two examples of Ant tasks.
|
||||
|
||||
|
||||
[[spring-boot-ant-findmainclass]]
|
||||
=== `spring-boot:findmainclass`
|
||||
=== Using the "`findmainclass`" Task
|
||||
The `findmainclass` task is used internally by `exejar` to locate a class declaring a `main`.
|
||||
If necessary, you can also use this task directly in your build.
|
||||
The following attributes are supported:
|
||||
|
||||
@@ -505,7 +505,7 @@ Spring Boot application can be easily started as Unix/Linux services by using ei
|
||||
|
||||
|
||||
[[deployment-initd-service]]
|
||||
==== Installation as an `init.d` Service (System V)
|
||||
==== Installation as an init.d Service (System V)
|
||||
If you configured Spring Boot's Maven or Gradle plugin to generate a <<deployment-install, fully executable jar>>, and you do not use a custom `embeddedLaunchScript`, your application can be used as an `init.d` service.
|
||||
To do so, symlink the jar to `init.d` to support the standard `start`, `stop`, `restart`, and `status` commands.
|
||||
|
||||
@@ -543,7 +543,7 @@ For example, on Debian, you could use the following command:
|
||||
|
||||
|
||||
[[deployment-initd-service-securing]]
|
||||
===== Securing an `init.d` Service
|
||||
===== Securing an init.d Service
|
||||
NOTE: The following is a set of guidelines on how to secure a Spring Boot application that runs as an init.d service.
|
||||
It is not intended to be an exhaustive list of everything that should be done to harden an application and the environment in which it runs.
|
||||
|
||||
@@ -594,7 +594,7 @@ Use `chmod` so that the file can only be read by the owner and use `chown` to ma
|
||||
|
||||
|
||||
[[deployment-systemd-service]]
|
||||
==== Installation as a `systemd` Service
|
||||
==== Installation as a systemd Service
|
||||
`systemd` is the successor of the System V init system and is now being used by many modern Linux distributions.
|
||||
Although you can continue to use `init.d` scripts with `systemd`, it is also possible to launch Spring Boot applications by using `systemd` '`service`' scripts.
|
||||
|
||||
|
||||
@@ -218,7 +218,7 @@ To use Spring property placeholders together with automatic expansion, escape th
|
||||
|
||||
|
||||
[[howto-externalize-configuration]]
|
||||
=== Externalize the Configuration of `SpringApplication`
|
||||
=== Externalize the Configuration of SpringApplication
|
||||
A `SpringApplication` has bean properties (mainly setters), so you can use its Java API as you create the application to modify its behavior.
|
||||
Alternatively, you can externalize the configuration by setting properties in `+spring.main.*+`.
|
||||
For example, in `application.properties`, you might have the following settings:
|
||||
@@ -1831,7 +1831,7 @@ If you use Spring Data, you need to configure `@EnableJpaRepositories` according
|
||||
|
||||
|
||||
[[howto-use-traditional-persistence-xml]]
|
||||
=== Use a Traditional `persistence.xml` File
|
||||
=== Use a Traditional persistence.xml File
|
||||
Spring Boot will not search for or use a `META-INF/persistence.xml` by default.
|
||||
If you prefer to use a traditional `persistence.xml`, you need to define your own `@Bean` of type `LocalEntityManagerFactoryBean` (with an ID of '`entityManagerFactory`') and set the persistence unit name there.
|
||||
|
||||
@@ -2611,7 +2611,7 @@ See {spring-boot-maven-plugin-docs}#run-example-debug[this example] for more det
|
||||
|
||||
|
||||
[[howto-build-an-executable-archive-with-ant]]
|
||||
=== Build an Executable Archive from Ant without Using `spring-boot-antlib`
|
||||
=== Build an Executable Archive from Ant without Using spring-boot-antlib
|
||||
To build with Ant, you need to grab dependencies, compile, and then create a jar or war archive.
|
||||
To make it executable, you can either use the `spring-boot-antlib` module or you can follow these instructions:
|
||||
|
||||
|
||||
@@ -408,7 +408,7 @@ You can mix class declarations with `beans{}` in the same file as long as they s
|
||||
|
||||
|
||||
[[cli-maven-settings]]
|
||||
== Configuring the CLI with `settings.xml`
|
||||
== Configuring the CLI with settings.xml
|
||||
The Spring Boot CLI uses Aether, Maven's dependency resolution engine, to resolve dependencies.
|
||||
The CLI makes use of the Maven configuration found in `~/.m2/settings.xml` to configure Aether.
|
||||
The following configuration settings are honored by the CLI:
|
||||
|
||||
@@ -1024,7 +1024,7 @@ TIP: If you have more than one constructor for your class you can also use `@Con
|
||||
|
||||
|
||||
[[boot-features-external-config-enabling]]
|
||||
==== Enabling `@ConfigurationProperties`-annotated types
|
||||
==== Enabling @ConfigurationProperties-annotated types
|
||||
Spring Boot provides infrastructure to bind `@ConfigurationProperties` types and register them as beans.
|
||||
You can either enable configuration properties on a class-by-class basis or enable configuration property scanning that works in a similar manner to component scanning.
|
||||
|
||||
@@ -1068,7 +1068,7 @@ If you still want to inject other beans using the constructor, the configuration
|
||||
|
||||
|
||||
[[boot-features-external-config-using]]
|
||||
==== Using `@ConfigurationProperties`-annotated types
|
||||
==== Using @ConfigurationProperties-annotated types
|
||||
This style of configuration works particularly well with the `SpringApplication` external YAML configuration, as shown in the following example:
|
||||
|
||||
[source,yaml,indent=0]
|
||||
@@ -3133,8 +3133,9 @@ Spring Boot will auto-configure the Spring Messaging infrastructure for RSocket.
|
||||
This means that Spring Boot will create a `RSocketMessageHandler` bean that will handle RSocket requests to your application.
|
||||
|
||||
|
||||
|
||||
[[boot-features-rsocket-requester]]
|
||||
=== Calling RSocket Services with `RSocketRequester`
|
||||
=== Calling RSocket Services with RSocketRequester
|
||||
Once the `RSocket` channel is established between server and client, any party can send or receive requests to the other.
|
||||
|
||||
As a server, you can get injected with an `RSocketRequester` instance on any handler method of an RSocket `@Controller`.
|
||||
@@ -5645,7 +5646,7 @@ spring.kafka.bootstrap-servers=${spring.embedded.kafka.brokers}
|
||||
|
||||
|
||||
[[boot-features-resttemplate]]
|
||||
== Calling REST Services with `RestTemplate`
|
||||
== Calling REST Services with RestTemplate
|
||||
If you need to call remote REST services from your application, you can use the Spring Framework's {spring-framework-api}/web/client/RestTemplate.html[`RestTemplate`] class.
|
||||
Since `RestTemplate` instances often need to be customized before being used, Spring Boot does not provide any single auto-configured `RestTemplate` bean.
|
||||
It does, however, auto-configure a `RestTemplateBuilder`, which can be used to create `RestTemplate` instances when needed.
|
||||
@@ -5699,7 +5700,7 @@ Doing so switches off the auto-configuration of a `RestTemplateBuilder` and prev
|
||||
|
||||
|
||||
[[boot-features-webclient]]
|
||||
== Calling REST Services with `WebClient`
|
||||
== Calling REST Services with WebClient
|
||||
If you have Spring WebFlux on your classpath, you can also choose to use `WebClient` to call remote REST services.
|
||||
Compared to `RestTemplate`, this client has a more functional feel and is fully reactive.
|
||||
You can learn more about the `WebClient` in the dedicated {spring-framework-docs}web-reactive.html#webflux-client[section in the Spring Framework docs].
|
||||
@@ -7414,7 +7415,7 @@ To do so, configure their location, as shown in the following example:
|
||||
|
||||
|
||||
[[boot-features-webservices-template]]
|
||||
=== Calling Web Services with `WebServiceTemplate`
|
||||
=== Calling Web Services with WebServiceTemplate
|
||||
If you need to call remote Web services from your application, you can use the {spring-webservices-docs}#client-web-service-template[`WebServiceTemplate`] class.
|
||||
Since `WebServiceTemplate` instances often need to be customized before being used, Spring Boot does not provide any single auto-configured `WebServiceTemplate` bean.
|
||||
It does, however, auto-configure a `WebServiceTemplateBuilder`, which can be used to create `WebServiceTemplate` instances when needed.
|
||||
@@ -7751,7 +7752,7 @@ Using your own starter in a compatible IDE is also a good idea to validate that
|
||||
|
||||
|
||||
[[boot-features-custom-starter-module-autoconfigure]]
|
||||
==== `autoconfigure` Module
|
||||
==== The "`autoconfigure`" Module
|
||||
The `autoconfigure` module contains everything that is necessary to get started with the library.
|
||||
It may also contain configuration key definitions (such as `@ConfigurationProperties`) and any callback interface that can be used to further customize how the components are initialized.
|
||||
|
||||
@@ -7915,7 +7916,7 @@ TIP: `org.jetbrains.kotlinx:kotlinx-coroutines-reactor` dependency is provided b
|
||||
|
||||
|
||||
[[boot-features-kotlin-configuration-properties]]
|
||||
=== `@ConfigurationProperties`
|
||||
=== @ConfigurationProperties
|
||||
`@ConfigurationProperties` when used in combination with <<boot-features-external-config-constructor-binding,`@ConstructorBinding`>> supports classes with immutable `val` properties as shown in the following example:
|
||||
|
||||
[source,kotlin,indent=0]
|
||||
|
||||
Reference in New Issue
Block a user