diff --git a/src/docs/asciidoc/core/core-aop.adoc b/src/docs/asciidoc/core/core-aop.adoc index bc100f83e5..51c077850c 100644 --- a/src/docs/asciidoc/core/core-aop.adoc +++ b/src/docs/asciidoc/core/core-aop.adoc @@ -3956,7 +3956,7 @@ for AspectJ LTW: * `spring-aop.jar` * `aspectjweaver.jar` -If you use the <>, you also need: * `spring-instrument.jar` diff --git a/src/docs/asciidoc/core/core-appendix.adoc b/src/docs/asciidoc/core/core-appendix.adoc index e047d3d8ea..ee20da30b4 100644 --- a/src/docs/asciidoc/core/core-appendix.adoc +++ b/src/docs/asciidoc/core/core-appendix.adoc @@ -666,7 +666,7 @@ integrate such parsers into the Spring IoC container. To facilitate authoring configuration files that use a schema-aware XML editor, Spring's extensible XML configuration mechanism is based on XML Schema. If you are not familiar with Spring's current XML configuration extensions that come with the standard -Spring distribution, you should first read the appendix entitled <>. +Spring distribution, you should first read the appendix entitled <>. To create new XML configuration extensions: diff --git a/src/docs/asciidoc/core/core-beans.adoc b/src/docs/asciidoc/core/core-beans.adoc index bbecd6c728..1b1af8d810 100644 --- a/src/docs/asciidoc/core/core-beans.adoc +++ b/src/docs/asciidoc/core/core-beans.adoc @@ -543,7 +543,7 @@ enforced by the container, though no longer by XML parsers. You are not required to supply a `name` or an `id` for a bean. If you do not supply a `name` or `id` explicitly, the container generates a unique name for that bean. However, if you want to refer to that bean by name, through the use of the `ref` element or a -<> style lookup, you must provide a name. +Service Locator style lookup, you must provide a name. Motivations for not supplying a name are related to using <> and <>. @@ -4482,7 +4482,7 @@ with placeholder values is defined: The example shows properties configured from an external `Properties` file. At runtime, a `PropertySourcesPlaceholderConfigurer` is applied to the metadata that replaces some properties of the DataSource. The values to replace are specified as placeholders of the -form `${property-name}`, which follows the Ant and log4j and JSP EL style. +form pass:q[`${property-name}`], which follows the Ant and log4j and JSP EL style. The actual values come from another file in the standard Java `Properties` format: @@ -9543,7 +9543,7 @@ now looks like the following listing: The problem is how to switch between using these two variations based on the current environment. Over time, Spring users have devised a number of ways to get this done, usually relying on a combination of system environment variables -and XML `` statements containing `${placeholder}` tokens that resolve +and XML `` statements containing pass:q[`${placeholder}`] tokens that resolve to the correct configuration file path depending on the value of an environment variable. Bean definition profiles is a core container feature that provides a solution to this problem. diff --git a/src/docs/asciidoc/data-access.adoc b/src/docs/asciidoc/data-access.adoc index b25cf89995..7d9795db52 100644 --- a/src/docs/asciidoc/data-access.adoc +++ b/src/docs/asciidoc/data-access.adoc @@ -1314,7 +1314,7 @@ NOTE: The `proxy-target-class` attribute controls what type of transactional pro created for classes annotated with the `@Transactional` annotation. If `proxy-target-class` is set to `true`, class-based proxies are created. If `proxy-target-class` is `false` or if the attribute is omitted, standard JDK -interface-based proxies are created. (See <> for a discussion of the +interface-based proxies are created. (See <> for a discussion of the different proxy types.) NOTE: `@EnableTransactionManagement` and `` looks for diff --git a/src/docs/asciidoc/languages/dynamic-languages.adoc b/src/docs/asciidoc/languages/dynamic-languages.adoc index eaf26b16c2..67a066ba2d 100644 --- a/src/docs/asciidoc/languages/dynamic-languages.adoc +++ b/src/docs/asciidoc/languages/dynamic-languages.adoc @@ -589,7 +589,7 @@ in the same place as Spring's `GroovyObjectCustomizer`. This section describes how to use BeanShell beans in Spring. -The BeanShell homepage includes the following description: {JB} +The BeanShell homepage includes the following description: "`BeanShell is a small, free, embeddable Java source interpreter with dynamic language features, written in Java. BeanShell dynamically executes standard Java syntax and diff --git a/src/docs/asciidoc/languages/kotlin.adoc b/src/docs/asciidoc/languages/kotlin.adoc index f449881b85..d9702e8a1f 100644 --- a/src/docs/asciidoc/languages/kotlin.adoc +++ b/src/docs/asciidoc/languages/kotlin.adoc @@ -748,12 +748,12 @@ as the following example shows: === Injecting Configuration Properties -In Java, you can inject configuration properties by using annotations (such as `@Value("${property}")`). +In Java, you can inject configuration properties by using annotations (such as pass:q[`@Value("${property}")`)]. However, in Kotlin, `$` is a reserved character that is used for https://kotlinlang.org/docs/reference/idioms.html#string-interpolation[string interpolation]. Therefore, if you wish to use the `@Value` annotation in Kotlin, you need to escape the `$` -character by writing `@Value("\${property}")`. +character by writing pass:q[`@Value("\${property}")`]. NOTE: If you use Spring Boot, you should probably use https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html#boot-features-external-config-typesafe-configuration-properties[`@ConfigurationProperties`] diff --git a/src/docs/asciidoc/rsocket.adoc b/src/docs/asciidoc/rsocket.adoc index 27df660097..6f00bc02e8 100644 --- a/src/docs/asciidoc/rsocket.adoc +++ b/src/docs/asciidoc/rsocket.adoc @@ -781,7 +781,7 @@ use the following method arguments: | `@DestinationVariable` | Value extracted from the route based on variables in the mapping pattern, e.g. - `@MessageMapping("find.radar.{id}")`. + pass:q[`@MessageMapping("find.radar.{id}")`]. | `@Header` | Metadata value registered for extraction as described in <>. diff --git a/src/docs/asciidoc/testing-webtestclient.adoc b/src/docs/asciidoc/testing-webtestclient.adoc index ef6414f06e..7138bd007b 100644 --- a/src/docs/asciidoc/testing-webtestclient.adoc +++ b/src/docs/asciidoc/testing-webtestclient.adoc @@ -1,5 +1,7 @@ [[webtestclient]] = WebTestClient +:doc-root: https://docs.spring.io +:api-spring-framework: {doc-root}/spring-framework/docs/{spring-version}/javadoc-api/org/springframework `WebTestClient` is a thin shell around <>, using it to perform requests and exposing a dedicated, fluent API for verifying responses. diff --git a/src/docs/asciidoc/web-reactive.adoc b/src/docs/asciidoc/web-reactive.adoc index 3e7df852a8..b913630dc0 100644 --- a/src/docs/asciidoc/web-reactive.adoc +++ b/src/docs/asciidoc/web-reactive.adoc @@ -10,7 +10,7 @@ This part of the documentation covers support for reactive-stack web applications built on a https://www.reactive-streams.org/[Reactive Streams] API to run on non-blocking servers, such as Netty, Undertow, and Servlet 3.1+ containers. Individual chapters cover -the <> framework, +the <> framework, the reactive <>, support for <>, and <>. For Servlet-stack web applications, see <>. diff --git a/src/docs/asciidoc/web/integration.adoc b/src/docs/asciidoc/web/integration.adoc index ba2442b64f..549c5f5cde 100644 --- a/src/docs/asciidoc/web/integration.adoc +++ b/src/docs/asciidoc/web/integration.adoc @@ -9,7 +9,7 @@ particular architecture, technology, or methodology (although it certainly recom some over others). This freedom to pick and choose the architecture, technology, or methodology that is most relevant to a developer and their development team is arguably most evident in the web area, where Spring provides its own web frameworks -(<> and <>) while, at the same time, +(<> and <>) while, at the same time, supporting integration with a number of popular third-party web frameworks. diff --git a/src/docs/asciidoc/web/webflux-functional.adoc b/src/docs/asciidoc/web/webflux-functional.adoc index a69c98976c..278ef11079 100644 --- a/src/docs/asciidoc/web/webflux-functional.adoc +++ b/src/docs/asciidoc/web/webflux-functional.adoc @@ -538,7 +538,7 @@ RouterFunction route = route() .add(otherRoute) // <4> .build(); ---- -<1> `GET /person/{id}` with an `Accept` header that matches JSON is routed to +<1> pass:q[`GET /person/{id}`] with an `Accept` header that matches JSON is routed to `PersonHandler.getPerson` <2> `GET /person` with an `Accept` header that matches JSON is routed to `PersonHandler.listPeople` @@ -562,7 +562,7 @@ RouterFunction route = route() POST("/person", handler::createPerson) // <3> }.and(otherRoute) // <4> ---- -<1> `GET /person/{id}` with an `Accept` header that matches JSON is routed to +<1> pass:q[`GET /person/{id}`] with an `Accept` header that matches JSON is routed to `PersonHandler.getPerson` <2> `GET /person` with an `Accept` header that matches JSON is routed to `PersonHandler.listPeople` @@ -854,4 +854,4 @@ Besides using the `filter` method on the router function builder, it is possible filter to an existing router function via `RouterFunction.filter(HandlerFilterFunction)`. NOTE: CORS support for functional endpoints is provided through a dedicated -<>. +<>. diff --git a/src/docs/asciidoc/web/webflux.adoc b/src/docs/asciidoc/web/webflux.adoc index 704867efef..7c279560fd 100644 --- a/src/docs/asciidoc/web/webflux.adoc +++ b/src/docs/asciidoc/web/webflux.adoc @@ -674,7 +674,7 @@ Spring WebFlux provides fine-grained support for CORS configuration through anno controllers. However, when you use it with Spring Security, we advise relying on the built-in `CorsFilter`, which must be ordered ahead of Spring Security's chain of filters. -See the section on <> and the <> for more details. +See the section on <> and the <> for more details. @@ -1960,7 +1960,7 @@ can require type conversion if the argument is declared as something other than For such cases, type conversion is automatically applied based on the configured converters. By default, simple types (such as `int`, `long`, `Date`, and others) are supported. Type conversion -can be customized through a `WebDataBinder` (see <>) or by registering +can be customized through a `WebDataBinder` (see <>) or by registering `Formatters` with the `FormattingConversionService` (see <>). @@ -2162,7 +2162,7 @@ to `false` or by declaring the argument with a `java.util.Optional` wrapper. Type conversion is applied automatically if the target method parameter type is not -`String`. See <>. +`String`. See <>. When a `@RequestParam` annotation is declared on a `Map` or `MultiValueMap` argument, the map is populated with all query parameters. @@ -2223,7 +2223,7 @@ The following example gets the value of the `Accept-Encoding` and `Keep-Alive` h <2> Get the value of the `Keep-Alive` header. Type conversion is applied automatically if the target method parameter type is not -`String`. See <>. +`String`. See <>. When a `@RequestHeader` annotation is used on a `Map`, `MultiValueMap`, or `HttpHeaders` argument, the map is populated @@ -2273,7 +2273,7 @@ The following code sample demonstrates how to get the cookie value: Type conversion is applied automatically if the target method parameter type is not -`String`. See <>. +`String`. See <>. [[webflux-ann-modelattrib-method-args]] @@ -3265,7 +3265,7 @@ controller-specific `Formatter` instances, as the following example shows: === Managing Exceptions [.small]#<># -`@Controller` and <> classes can have +`@Controller` and <> classes can have `@ExceptionHandler` methods to handle exceptions from controller methods. The following example includes such a handler method: diff --git a/src/docs/asciidoc/web/webmvc-cors.adoc b/src/docs/asciidoc/web/webmvc-cors.adoc index a5c60e03df..aee826ced2 100644 --- a/src/docs/asciidoc/web/webmvc-cors.adoc +++ b/src/docs/asciidoc/web/webmvc-cors.adoc @@ -325,7 +325,7 @@ as the following example shows: [[mvc-cors-filter]] == CORS Filter -[.small]#<># +[.small]#<># You can apply CORS support through the built-in {api-spring-framework}/web/filter/CorsFilter.html[`CorsFilter`]. diff --git a/src/docs/asciidoc/web/webmvc-functional.adoc b/src/docs/asciidoc/web/webmvc-functional.adoc index 51d8b2b2b0..7f502e5694 100644 --- a/src/docs/asciidoc/web/webmvc-functional.adoc +++ b/src/docs/asciidoc/web/webmvc-functional.adoc @@ -475,7 +475,7 @@ The following example shows the composition of four routes: .add(otherRoute) // <4> .build(); ---- -<1> `GET /person/{id}` with an `Accept` header that matches JSON is routed to +<1> pass:q[`GET /person/{id}`] with an `Accept` header that matches JSON is routed to `PersonHandler.getPerson` <2> `GET /person` with an `Accept` header that matches JSON is routed to `PersonHandler.listPeople` @@ -500,7 +500,7 @@ The following example shows the composition of four routes: POST("/person", handler::createPerson) // <3> }.and(otherRoute) // <4> ---- -<1> `GET /person/{id}` with an `Accept` header that matches JSON is routed to +<1> pass:q[`GET /person/{id}`] with an `Accept` header that matches JSON is routed to `PersonHandler.getPerson` <2> `GET /person` with an `Accept` header that matches JSON is routed to `PersonHandler.listPeople` @@ -787,4 +787,4 @@ Besides using the `filter` method on the router function builder, it is possible filter to an existing router function via `RouterFunction.filter(HandlerFilterFunction)`. NOTE: CORS support for functional endpoints is provided through a dedicated -<>. +<>. diff --git a/src/docs/asciidoc/web/websocket.adoc b/src/docs/asciidoc/web/websocket.adoc index 3cc268b01a..9a0c5a68ba 100644 --- a/src/docs/asciidoc/web/websocket.adoc +++ b/src/docs/asciidoc/web/websocket.adoc @@ -512,9 +512,9 @@ https://host:port/myApp/myEndpoint/{server-id}/{session-id}/{transport} where: -* `{server-id}` is useful for routing requests in a cluster but is not used otherwise. -* `{session-id}` correlates HTTP requests belonging to a SockJS session. -* `{transport}` indicates the transport type (for example, `websocket`, `xhr-streaming`, and others). +* pass:q[`{server-id}`] is useful for routing requests in a cluster but is not used otherwise. +* pass:q[`{session-id}`] correlates HTTP requests belonging to a SockJS session. +* pass:q[`{transport}`] indicates the transport type (for example, `websocket`, `xhr-streaming`, and others). The WebSocket transport needs only a single HTTP request to do the WebSocket handshake. All messages thereafter are exchanged on that socket. @@ -1254,7 +1254,7 @@ level, `@MessageMapping` is used to express shared mappings across all methods i controller. By default, the mapping values are Ant-style path patterns (for example `/thing*`, `/thing/**`), -including support for template variables (for example, `/thing/{id}`). The values can be +including support for template variables (for example, pass:q[`/thing/{id}`]). The values can be referenced through `@DestinationVariable` method arguments. Applications can also switch to a dot-separated destination convention for mappings, as explained in <>. @@ -1862,7 +1862,7 @@ with other users who subscribe to the same destination so that each user can rec unique stock position updates. On the sending side, messages can be sent to a destination such as -`/user/{username}/queue/position-updates`, which in turn is translated +pass:q[`/user/{username}/queue/position-updates`], which in turn is translated by the `UserDestinationMessageHandler` into one or more destinations, one for each session associated with the user. This lets any component within the application send messages that target a specific user without necessarily knowing anything more