Don't use monospacing in documentation headings
Closes gh-20875
This commit is contained in:
parent
e17d4be484
commit
d9fb4dd477
|
@ -6,7 +6,7 @@ The `configprops` endpoint provides information about the application's `@Config
|
|||
|
||||
|
||||
[[configprops-retrieving]]
|
||||
== Retrieving the `@ConfigurationProperties` Bean
|
||||
== Retrieving the @ConfigurationProperties Bean
|
||||
|
||||
To retrieve the `@ConfigurationProperties` beans, make a `GET` request to `/actuator/configprops`, as shown in the following curl-based example:
|
||||
|
||||
|
|
|
@ -28,7 +28,7 @@ Spring Boot provides `build` and `git` contributions.
|
|||
|
||||
|
||||
[[info-retrieving-response-structure-build]]
|
||||
==== `build` Response Structure
|
||||
==== Build Response Structure
|
||||
|
||||
The following table describe the structure of the `build` section of the response:
|
||||
|
||||
|
@ -38,7 +38,7 @@ include::{snippets}/info/response-fields-beneath-build.adoc[]
|
|||
|
||||
|
||||
[[info-retrieving-response-structure-git]]
|
||||
==== `git` Response Structure
|
||||
==== Git Response Structure
|
||||
|
||||
The following table describes the structure of the `git` section of the response:
|
||||
|
||||
|
|
|
@ -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]
|
||||
|
|
|
@ -247,7 +247,7 @@ include::../gradle/packaging/boot-jar-custom-launch-script.gradle.kts[tags=custo
|
|||
|
||||
|
||||
[[packaging-executable-configuring-properties-launcher]]
|
||||
==== Using the `PropertiesLauncher`
|
||||
==== Using the PropertiesLauncher
|
||||
To use the `PropertiesLauncher` to launch an executable jar or war, configure the task's manifest to set the `Main-Class` attribute:
|
||||
|
||||
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
|
||||
|
|
|
@ -4,7 +4,7 @@
|
|||
|
||||
|
||||
[[publishing-your-application-maven]]
|
||||
=== Publishing with the `maven` Plugin
|
||||
=== Publishing with the Maven Plugin
|
||||
When the {maven-plugin}[`maven` plugin] is applied, an `Upload` task for the `bootArchives` configuration named `uploadBootArchives` is automatically created.
|
||||
By default, the `bootArchives` configuration contains the archive produced by the `bootJar` or `bootWar` task.
|
||||
The `uploadBootArchives` task can be configured to publish the archive to a Maven repository:
|
||||
|
@ -24,7 +24,7 @@ include::../gradle/publishing/maven.gradle.kts[tags=upload]
|
|||
|
||||
|
||||
[[publishing-your-application-maven-publish]]
|
||||
=== Publishing with the `maven-publish` Plugin
|
||||
=== Publishing with the Maven-publish Plugin
|
||||
To publish your Spring Boot jar or war, add it to the publication using the `artifact` method on `MavenPublication`.
|
||||
Pass the task that produces that artifact that you wish to publish to the `artifact` method.
|
||||
For example, to publish the artifact produced by the default `bootJar` task:
|
||||
|
@ -44,7 +44,7 @@ include::../gradle/publishing/maven-publish.gradle.kts[tags=publishing]
|
|||
|
||||
|
||||
[[publishing-your-application-distribution]]
|
||||
=== Distributing with the `application` Plugin
|
||||
=== Distributing with the Application Plugin
|
||||
When the {application-plugin}[`application` plugin] is applied a distribution named `boot` is created.
|
||||
This distribution contains the archive produced by the `bootJar` or `bootWar` task and scripts to launch it on Unix-like platforms and Windows.
|
||||
Zip and tar distributions can be built by the `bootDistZip` and `bootDistTar` tasks respectively.
|
||||
|
|
|
@ -6,7 +6,7 @@ This section describes those changes.
|
|||
|
||||
|
||||
[[reacting-to-other-plugins-java]]
|
||||
=== Reacting to the `java` Plugin
|
||||
=== Reacting to the Java Plugin
|
||||
When Gradle's {java-plugin}[`java` plugin] is applied to a project, the Spring Boot plugin:
|
||||
|
||||
1. Creates a {boot-jar-javadoc}[`BootJar`] task named `bootJar` that will create an executable, fat jar for the project.
|
||||
|
@ -32,7 +32,7 @@ When {kotlin-plugin}[Kotlin's Gradle plugin] is applied to a project, the Spring
|
|||
|
||||
|
||||
[[reacting-to-other-plugins-war]]
|
||||
=== Reacting to the `war` Plugin
|
||||
=== Reacting to the War Plugin
|
||||
When Gradle's {war-plugin}[`war` plugin] is applied to a project, the Spring Boot plugin:
|
||||
|
||||
1. Creates a {boot-war-javadoc}[`BootWar`] task named `bootWar` that will create an executable, fat war for the project.
|
||||
|
@ -50,7 +50,7 @@ When the {dependency-management-plugin}[`io.spring.dependency-management` plugin
|
|||
|
||||
|
||||
[[reacting-to-other-plugins-application]]
|
||||
=== Reacting to the `application` Plugin
|
||||
=== Reacting to the Application Plugin
|
||||
When Gradle's {application-plugin}[`application` plugin] is applied to a project, the Spring Boot plugin:
|
||||
|
||||
1. Creates a `CreateStartScripts` task named `bootStartScripts` that will create scripts that launch the artifact in the `bootArchives` configuration using `java -jar`.
|
||||
|
@ -64,5 +64,5 @@ When Gradle's {application-plugin}[`application` plugin] is applied to a project
|
|||
|
||||
|
||||
[[reacting-to-other-plugins-maven]]
|
||||
=== Reacting to the `maven` plugin
|
||||
=== Reacting to the Maven plugin
|
||||
When Gradle's {maven-plugin}[`maven` plugin] is applied to a project, the Spring Boot plugin will configure the `uploadBootArchives` `Upload` task to ensure that no dependencies are declared in the pom that it generates.
|
||||
|
|
Loading…
Reference in New Issue