@ -543,7 +543,7 @@ enforced by the container, though no longer by XML parsers.
@@ -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
<<beans-servicelocator,Service Locator>> 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 <<beans-inner-beans,inner
beans>> and <<beans-factory-autowire,autowiring collaborators>>.
@ -4482,7 +4482,7 @@ with placeholder values is defined:
@@ -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:
@@ -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 `<import/>` statements containing `${placeholder}` tokens that resolve
and XML `<import/>` 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
@ -1314,7 +1314,7 @@ NOTE: The `proxy-target-class` attribute controls what type of transactional pro
@@ -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 <<aop-proxying>> for a discussion of the
interface-based proxies are created. (See <<core.adoc#aop-proxying>> for a discussion of the
different proxy types.)
NOTE: `@EnableTransactionManagement` and `<tx:annotation-driven/>` looks for
<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
@@ -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
@ -674,7 +674,7 @@ Spring WebFlux provides fine-grained support for CORS configuration through anno
@@ -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 <<webflux-cors>> and the <<webflux-cors-webfilter>> for more details.
See the section on <<webflux-cors>> and the <<webflux-cors.adoc#webflux-cors-webfilter>> for more details.
@ -1960,7 +1960,7 @@ can require type conversion if the argument is declared as something other than
@@ -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 <<mvc-ann-initbinder>>) or by registering
can be customized through a `WebDataBinder` (see <<webflux-ann-initbinder>>) or by registering
`Formatters` with the `FormattingConversionService` (see <<core.adoc#format, Spring Field Formatting>>).
@ -2162,7 +2162,7 @@ to `false` or by declaring the argument with a `java.util.Optional`
@@ -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 <<mvc-ann-typeconversion>>.
`String`. See <<webflux-ann-typeconversion>>.
When a `@RequestParam` annotation is declared on a `Map<String, String>` or
`MultiValueMap<String, String>` 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
@@ -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 <<mvc-ann-typeconversion>>.
`String`. See <<webflux-ann-typeconversion>>.
When a `@RequestHeader` annotation is used on a `Map<String, String>`,
`MultiValueMap<String, String>`, or `HttpHeaders` argument, the map is populated
@ -2273,7 +2273,7 @@ The following code sample demonstrates how to get the cookie value:
@@ -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 <<mvc-ann-typeconversion>>.
`String`. See <<webflux-ann-typeconversion>>.
[[webflux-ann-modelattrib-method-args]]
@ -3265,7 +3265,7 @@ controller-specific `Formatter` instances, as the following example shows:
@@ -3265,7 +3265,7 @@ controller-specific `Formatter` instances, as the following example shows:
=== Managing Exceptions
[.small]#<<web.adoc#mvc-ann-exceptionhandler, Web MVC>>#
`@Controller` and <<mvc-ann-controller-advice, @ControllerAdvice>> classes can have
`@Controller` and <<webflux-ann-controller-advice, @ControllerAdvice>> classes can have
`@ExceptionHandler` methods to handle exceptions from controller methods. The following
@ -475,7 +475,7 @@ The following example shows the composition of four routes:
@@ -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:
@@ -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
@@ -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
* `{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
@@ -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
<<websocket-stomp-destination-separator>>.
@ -1862,7 +1862,7 @@ with other users who subscribe to the same destination so that each user can rec
@@ -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