Escape additional '{reference}' elements in asciidoc
Escape lines that look like variable references but should actually be included verbatim. Closes gh-17386
This commit is contained in:
parent
a81f37dd68
commit
88b6a3308c
|
|
@ -206,7 +206,7 @@ properties (System properties, environment variables, manifest entries, or
|
|||
|Key |Purpose
|
||||
|
||||
|`loader.path`
|
||||
|Comma-separated Classpath, such as `lib,${HOME}/app/lib`. Earlier entries take
|
||||
|Comma-separated Classpath, such as `lib,$\{HOME}/app/lib`. Earlier entries take
|
||||
precedence, like a regular `-classpath` on the `javac` command line.
|
||||
|
||||
|`loader.home`
|
||||
|
|
|
|||
|
|
@ -233,7 +233,7 @@ You also need to include the following element inside `<plugins/>`:
|
|||
----
|
||||
|
||||
NOTE: The `useDefaultDelimiters` property is important if you use standard Spring
|
||||
placeholders (such as `${placeholder}`) in your configuration. If that property is not
|
||||
placeholders (such as `$\{placeholder}`) in your configuration. If that property is not
|
||||
set to `false`, these may be expanded by the build.
|
||||
|
||||
|
||||
|
|
@ -474,7 +474,7 @@ NOTE: The YAML documents are merged in the order in which they are encountered.
|
|||
values override earlier values.
|
||||
|
||||
To do the same thing with properties files, you can use
|
||||
`application-${profile}.properties` to specify profile-specific values.
|
||||
`application-$\{profile}.properties` to specify profile-specific values.
|
||||
|
||||
|
||||
|
||||
|
|
@ -1558,11 +1558,11 @@ want to set levels, as shown in the following example:
|
|||
If you look at `base.xml` in the spring-boot jar, you can see that it uses
|
||||
some useful System properties that the `LoggingSystem` takes care of creating for you:
|
||||
|
||||
* `${PID}`: The current process ID.
|
||||
* `${LOG_FILE}`: Whether `logging.file` was set in Boot's external configuration.
|
||||
* `${LOG_PATH}`: Whether `logging.path` (representing a directory for
|
||||
* `$\{PID}`: The current process ID.
|
||||
* `$\{LOG_FILE}`: Whether `logging.file` was set in Boot's external configuration.
|
||||
* `$\{LOG_PATH}`: Whether `logging.path` (representing a directory for
|
||||
log files to live in) was set in Boot's external configuration.
|
||||
* `${LOG_EXCEPTION_CONVERSION_WORD}`: Whether `logging.exception-conversion-word` was set
|
||||
* `$\{LOG_EXCEPTION_CONVERSION_WORD}`: Whether `logging.exception-conversion-word` was set
|
||||
in Boot's external configuration.
|
||||
|
||||
Spring Boot also provides some nice ANSI color terminal output on a console (but not in
|
||||
|
|
@ -2242,7 +2242,7 @@ It is a Hibernate feature (and has nothing to do with Spring).
|
|||
Spring Boot can automatically create the schema (DDL scripts) of your `DataSource` and
|
||||
initialize it (DML scripts). It loads SQL from the standard root classpath locations:
|
||||
`schema.sql` and `data.sql`, respectively. In addition, Spring Boot processes the
|
||||
`schema-${platform}.sql` and `data-${platform}.sql` files (if present), where `platform`
|
||||
`schema-$\{platform}.sql` and `data-$\{platform}.sql` files (if present), where `platform`
|
||||
is the value of `spring.datasource.platform`. This allows you to switch to
|
||||
database-specific scripts if necessary. For example, you might choose to set it to the
|
||||
vendor name of the database (`hsqldb`, `h2`, `oracle`, `mysql`, `postgresql`, and so on).
|
||||
|
|
@ -2308,12 +2308,12 @@ scripts in both the default classpath location and the `/opt/migration` director
|
|||
spring.flyway.locations=classpath:db/migration,filesystem:/opt/migration
|
||||
----
|
||||
|
||||
You can also add a special `{vendor}` placeholder to use vendor-specific scripts. Assume
|
||||
You can also add a special `\{vendor}` placeholder to use vendor-specific scripts. Assume
|
||||
the following:
|
||||
|
||||
[source,properties,indent=0]
|
||||
----
|
||||
spring.flyway.locations=classpath:db/migration/{vendor}
|
||||
spring.flyway.locations=classpath:db/migration/\{vendor}
|
||||
----
|
||||
|
||||
Rather than using `db/migration`, the preceding configuration sets the folder to use
|
||||
|
|
|
|||
|
|
@ -1099,7 +1099,7 @@ management endpoint, as shown in the following example:
|
|||
----
|
||||
|
||||
The preceding `application.properties` example changes the endpoint from
|
||||
`/actuator/{id}` to `/manage/{id}` (for example, `/manage/info`).
|
||||
`/actuator/\{id}` to `/manage/\{id}` (for example, `/manage/info`).
|
||||
|
||||
NOTE: Unless the management port has been configured to
|
||||
<<production-ready-customizing-management-server-port,expose endpoints by using a
|
||||
|
|
@ -1376,7 +1376,7 @@ https://micrometer.io/docs[reference documentation], in particular the
|
|||
=== Getting started
|
||||
Spring Boot auto-configures a composite `MeterRegistry` and adds a registry to the
|
||||
composite for each of the supported implementations that it finds on the classpath. Having
|
||||
a dependency on `micrometer-registry-{system}` in your runtime classpath is enough for
|
||||
a dependency on `micrometer-registry-\{system}` in your runtime classpath is enough for
|
||||
Spring Boot to configure the registry.
|
||||
|
||||
Most registries share common features. For instance, you can disable a particular registry
|
||||
|
|
@ -1846,7 +1846,7 @@ By default, Spring MVC-related metrics are tagged with the following information
|
|||
|
||||
|`uri`
|
||||
|Request's URI template prior to variable substitution, if possible (for example,
|
||||
`/api/person/{id}`)
|
||||
`/api/person/\{id}`)
|
||||
|
||||
|===
|
||||
|
||||
|
|
@ -1883,7 +1883,7 @@ By default, WebFlux-related metrics are tagged with the following information:
|
|||
|
||||
|`uri`
|
||||
|Request's URI template prior to variable substitution, if possible (for example,
|
||||
`/api/person/{id}`)
|
||||
`/api/person/\{id}`)
|
||||
|
||||
|===
|
||||
|
||||
|
|
@ -1940,7 +1940,7 @@ By default, Jersey server metrics are tagged with the following information:
|
|||
|
||||
|`uri`
|
||||
|Request's URI template prior to variable substitution, if possible (for example,
|
||||
`/api/person/{id}`)
|
||||
`/api/person/\{id}`)
|
||||
|
||||
|===
|
||||
|
||||
|
|
@ -1968,7 +1968,7 @@ following information:
|
|||
|
||||
* `method`, the request's method (for example, `GET` or `POST`).
|
||||
* `uri`, the request's URI template prior to variable substitution, if possible (for
|
||||
example, `/api/person/{id}`).
|
||||
example, `/api/person/\{id}`).
|
||||
* `status`, the response's HTTP status code (for example, `200` or `500`).
|
||||
* `clientName`, the host portion of the URI.
|
||||
|
||||
|
|
|
|||
|
|
@ -418,9 +418,9 @@ variable or system property).
|
|||
. A `RandomValuePropertySource` that has properties only in `+random.*+`.
|
||||
. <<boot-features-external-config-profile-specific-properties,Profile-specific
|
||||
application properties>> outside of your packaged jar
|
||||
(`application-{profile}.properties` and YAML variants).
|
||||
(`application-\{profile}.properties` and YAML variants).
|
||||
. <<boot-features-external-config-profile-specific-properties,Profile-specific
|
||||
application properties>> packaged inside your jar (`application-{profile}.properties`
|
||||
application properties>> packaged inside your jar (`application-\{profile}.properties`
|
||||
and YAML variants).
|
||||
. Application properties outside of your packaged jar (`application.properties` and YAML
|
||||
variants).
|
||||
|
|
@ -614,7 +614,7 @@ environment variables or system properties.
|
|||
[[boot-features-external-config-profile-specific-properties]]
|
||||
=== Profile-specific Properties
|
||||
In addition to `application.properties` files, profile-specific properties can also be
|
||||
defined by using the following naming convention: `application-{profile}.properties`. The
|
||||
defined by using the following naming convention: `application-\{profile}.properties`. The
|
||||
`Environment` has a set of default profiles (by default, `[default]`) that are used if no
|
||||
active profiles are set. In other words, if no profiles are explicitly activated, then
|
||||
properties from `application-default.properties` are loaded.
|
||||
|
|
@ -859,7 +859,7 @@ to using only one of them.
|
|||
|
||||
[[boot-features-external-config-typesafe-configuration-properties]]
|
||||
=== Type-safe Configuration Properties
|
||||
Using the `@Value("${property}")` annotation to inject configuration properties can
|
||||
Using the `@Value("$\{property}")` annotation to inject configuration properties can
|
||||
sometimes be cumbersome, especially if you are working with multiple properties or your
|
||||
data is hierarchical in nature. Spring Boot provides an alternative method of working
|
||||
with properties that lets strongly typed beans govern and validate the configuration of
|
||||
|
|
@ -1919,7 +1919,7 @@ as the delimiter between a property name and its default value and not use `:-`.
|
|||
|
||||
You can add MDC and other ad-hoc content to log lines by overriding only the
|
||||
`LOG_LEVEL_PATTERN` (or `logging.pattern.level` with Logback). For example, if you use
|
||||
`logging.pattern.level=user:%X{user} %5p`, then the default log format contains an MDC
|
||||
`logging.pattern.level=user:%X\{user} %5p`, then the default log format contains an MDC
|
||||
entry for "user", if it exists, as shown in the following example.
|
||||
|
||||
----
|
||||
|
|
@ -2103,17 +2103,17 @@ The following code shows a typical `@RestController` that serves JSON data:
|
|||
@RequestMapping(value="/users")
|
||||
public class MyRestController {
|
||||
|
||||
@RequestMapping(value="/{user}", method=RequestMethod.GET)
|
||||
@RequestMapping(value="/\{user}", method=RequestMethod.GET)
|
||||
public User getUser(@PathVariable Long user) {
|
||||
// ...
|
||||
}
|
||||
|
||||
@RequestMapping(value="/{user}/customers", method=RequestMethod.GET)
|
||||
@RequestMapping(value="/\{user}/customers", method=RequestMethod.GET)
|
||||
List<Customer> getUserCustomers(@PathVariable Long user) {
|
||||
// ...
|
||||
}
|
||||
|
||||
@RequestMapping(value="/{user}", method=RequestMethod.DELETE)
|
||||
@RequestMapping(value="/\{user}", method=RequestMethod.DELETE)
|
||||
public User deleteUser(@PathVariable Long user) {
|
||||
// ...
|
||||
}
|
||||
|
|
@ -2704,17 +2704,17 @@ following example:
|
|||
@RequestMapping("/users")
|
||||
public class MyRestController {
|
||||
|
||||
@GetMapping("/{user}")
|
||||
@GetMapping("/\{user}")
|
||||
public Mono<User> getUser(@PathVariable Long user) {
|
||||
// ...
|
||||
}
|
||||
|
||||
@GetMapping("/{user}/customers")
|
||||
@GetMapping("/\{user}/customers")
|
||||
public Flux<Customer> getUserCustomers(@PathVariable Long user) {
|
||||
// ...
|
||||
}
|
||||
|
||||
@DeleteMapping("/{user}")
|
||||
@DeleteMapping("/\{user}")
|
||||
public Mono<User> deleteUser(@PathVariable Long user) {
|
||||
// ...
|
||||
}
|
||||
|
|
@ -2732,9 +2732,9 @@ actual handling of the requests, as shown in the following example:
|
|||
|
||||
@Bean
|
||||
public RouterFunction<ServerResponse> monoRouterFunction(UserHandler userHandler) {
|
||||
return route(GET("/{user}").and(accept(APPLICATION_JSON)), userHandler::getUser)
|
||||
.andRoute(GET("/{user}/customers").and(accept(APPLICATION_JSON)), userHandler::getUserCustomers)
|
||||
.andRoute(DELETE("/{user}").and(accept(APPLICATION_JSON)), userHandler::deleteUser);
|
||||
return route(GET("/\{user}").and(accept(APPLICATION_JSON)), userHandler::getUser)
|
||||
.andRoute(GET("/\{user}/customers").and(accept(APPLICATION_JSON)), userHandler::getUserCustomers)
|
||||
.andRoute(DELETE("/\{user}").and(accept(APPLICATION_JSON)), userHandler::deleteUser);
|
||||
}
|
||||
|
||||
}
|
||||
|
|
|
|||
Loading…
Reference in New Issue