Merge branch '5.2.x'

src/docs/asciidoc/web/webflux-functional.adoc

@@ -573,14 +573,13 @@ RouterFunction<ServerResponse> route = route()
 
 === Nested Routes
 
-It is common for a group of router functions to have a shared predicate, for instance a shared
-path.
-In the example above, the shared predicate would be a path predicate that matches `/person`,
-used by three of the routes.
-When using annotations, you would remove this duplication by using a type-level `@RequestMapping`
- annotation that maps to `/person`.
-In WebFlux.fn, path predicates can be shared through the `path` method on the router function builder.
-For instance, the last few lines of the example above can be improved in the following way by using nested routes:
+It is common for a group of router functions to have a shared predicate, for instance a
+shared path. In the example above, the shared predicate would be a path predicate that
+matches `/person`, used by three of the routes. When using annotations, you would remove
+this duplication by using a type-level `@RequestMapping` annotation that maps to
+`/person`. In WebFlux.fn, path predicates can be shared through the `path` method on the
+router function builder. For instance, the last few lines of the example above can be
+improved in the following way by using nested routes:
 
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
 .Java
@@ -848,7 +847,7 @@ The following example shows how to do so:
 ----
 
 The preceding example demonstrates that invoking the `next.handle(ServerRequest)` is optional.
-We allow only the handler function to be executed when access is allowed.
+We only let the handler function be run when access is allowed.
 
 Besides using the `filter` method on the router function builder, it is possible to apply a
 filter to an existing router function via `RouterFunction.filter(HandlerFilterFunction)`.

src/docs/asciidoc/web/webflux-websocket.adoc

@@ -128,7 +128,7 @@ requirements, the unified flow completes when:
 * At a chosen point, through the `close` method of `WebSocketSession`.
 
 When inbound and outbound message streams are composed together, there is no need to
-check if the connection is open, since Reactive Streams signals terminate activity.
+check if the connection is open, since Reactive Streams signals end activity.
 The inbound stream receives a completion or error signal, and the outbound stream
 receives a cancellation signal.
 
@@ -369,7 +369,7 @@ WebSocket options when running on Tomcat:
 		@Bean
 		fun webSocketService(): WebSocketService {
 			val strategy = TomcatRequestUpgradeStrategy().apply {
-				setMaxSessionIdleTimeout(0L)	
+				setMaxSessionIdleTimeout(0L)
 			}
 			return HandshakeWebSocketService(strategy)
 		}

src/docs/asciidoc/web/webflux.adoc

@@ -101,7 +101,7 @@ operations on the output, but you need to adapt the output for use with another
 Whenever feasible (for example, annotated controllers), WebFlux adapts transparently to the use
 of RxJava or another reactive library. See <<webflux-reactive-libraries>> for more details.
 
-NOTE: In addition to Reactive APIs, WebFlux can also be used with 
+NOTE: In addition to Reactive APIs, WebFlux can also be used with
 <<languages.adoc#coroutines, Coroutines>> APIs in Kotlin which provides a more imperative style of programming.
 The following Kotlin code samples will be provided with Coroutines APIs.
 
@@ -218,7 +218,7 @@ For Undertow, Spring WebFlux uses Undertow APIs directly without the Servlet API
 
 Performance has many characteristics and meanings. Reactive and non-blocking generally
 do not make applications run faster. They can, in some cases, (for example, if using the
-`WebClient` to execute remote calls in parallel). On the whole, it requires more work to do
+`WebClient` to run remote calls in parallel). On the whole, it requires more work to do
 things the non-blocking way and that can slightly increase the required processing time.
 
 The key expected benefit of reactive and non-blocking is the ability to scale with a small,
@@ -894,7 +894,7 @@ not meet the stated goals, please let us know.
 [[webflux-logging-id]]
 ==== Log Id
 
-In WebFlux, a single request can be executed over multiple threads and the thread ID
+In WebFlux, a single request can be run over multiple threads and the thread ID
 is not useful for correlating log messages that belong to a specific request. This is why
 WebFlux log messages are prefixed with a request-specific ID by default.
 
@@ -1105,7 +1105,7 @@ many extra convenient options.
 `DispatcherHandler` processes requests as follows:
 
 * Each `HandlerMapping` is asked to find a matching handler, and the first match is used.
-* If a handler is found, it is executed through an appropriate `HandlerAdapter`, which
+* If a handler is found, it is run through an appropriate `HandlerAdapter`, which
 exposes the return value from the execution as `HandlerResult`.
 * The `HandlerResult` is given to an appropriate `HandlerResultHandler` to complete
 processing by writing to the response directly or by using a view to render.
@@ -4023,7 +4023,7 @@ underlying FreeMarker view technology):
 	@Configuration
 	@EnableWebFlux
 	class WebConfig : WebFluxConfigurer {
-		
+
 		override fun configureViewResolvers(registry: ViewResolverRegistry) {
 			registry.freeMarker()
 		}

src/docs/asciidoc/web/webmvc-functional.adoc

@@ -781,7 +781,7 @@ The following example shows how to do so:
 ----
 
 The preceding example demonstrates that invoking the `next.handle(ServerRequest)` is optional.
-We allow only the handler function to be executed when access is allowed.
+We only let the handler function be run when access is allowed.
 
 Besides using the `filter` method on the router function builder, it is possible to apply a
 filter to an existing router function via `RouterFunction.filter(HandlerFilterFunction)`.

src/docs/asciidoc/web/webmvc.adoc

@@ -518,7 +518,7 @@ The `DispatcherServlet` processes requests as follows:
   information about multipart handling.
 * An appropriate handler is searched for. If a handler is found, the execution chain
   associated with the handler (preprocessors, postprocessors, and controllers) is
-  executed in order to prepare a model or rendering. Alternatively, for annotated
+  run to prepare a model for rendering. Alternatively, for annotated
   controllers, the response can be rendered (within the `HandlerAdapter`) instead of
   returning a view.
 * If a model is returned, the view is rendered. If no model is returned (maybe due to
@@ -584,8 +584,8 @@ a principal. Interceptors must implement `HandlerInterceptor` from the
 `org.springframework.web.servlet` package with three methods that should provide enough
 flexibility to do all kinds of pre-processing and post-processing:
 
-* `preHandle(..)`: Before the actual handler is executed
-* `postHandle(..)`: After the handler is executed
+* `preHandle(..)`: Before the actual handler is run
+* `postHandle(..)`: After the handler is run
 * `afterCompletion(..)`: After the complete request has finished
 
 The `preHandle(..)` method returns a boolean value. You can use this method to break or
@@ -949,7 +949,7 @@ The `SessionLocaleResolver` lets you retrieve `Locale` and `TimeZone` from the
 session that might be associated with the user's request. In contrast to
 `CookieLocaleResolver`, this strategy stores locally chosen locale settings in the
 Servlet container's `HttpSession`. As a consequence, those settings are temporary
-for each session and are, therefore, lost when each session terminates.
+for each session and are, therefore, lost when each session ends.
 
 Note that there is no direct relationship with external session management mechanisms,
 such as the Spring Session project. This `SessionLocaleResolver` evaluates and
@@ -4593,7 +4593,7 @@ TIP: Spring MVC supports Reactor and RxJava through the
 `spring-core`, which lets it adapt from multiple reactive libraries.
 
 For streaming to the response, reactive back pressure is supported, but writes to the
-response are still blocking and are executed on a separate thread through the
+response are still blocking and are run on a separate thread through the
 <<mvc-ann-async-configuration-spring-mvc, configured>> `TaskExecutor`, to avoid
 blocking the upstream source (such as a `Flux` returned from `WebClient`).
 By default, `SimpleAsyncTaskExecutor` is used for the blocking writes, but that is not
@@ -5410,7 +5410,7 @@ The following example shows how to achieve the same configuration in XML:
 
 This is a shortcut for defining a `ParameterizableViewController` that immediately
 forwards to a view when invoked. You can use it in static cases when there is no Java controller
-logic to execute before the view generates the response.
+logic to run before the view generates the response.
 
 The following example of Java configuration forwards a request for `/` to a view called `home`:
 
@@ -5934,7 +5934,7 @@ hook of the Spring `ApplicationContext`, as the following example shows:
 ----
 	@Component
 	class MyPostProcessor : BeanPostProcessor {
-		
+
 		override fun postProcessBeforeInitialization(bean: Any, name: String): Any {
 			// ...
 		}