Fix many doc typos according to IDEA suggestions

Author: artembilan

src/reference/antora/modules/ROOT/pages/aggregator.adoc

@@ -3,7 +3,7 @@
 
 Spring Integration provides channel adapters for receiving and sending messages by using the Advanced Message Queuing Protocol (AMQP).
 
-You need to include this dependency into your project:
+This dependency is required for the project:
 
 [tabs]
 ======

src/reference/antora/modules/ROOT/pages/amqp.adoc

@@ -1,10 +1,10 @@
 [[alternative-confirms-returns]]
 = Alternative Mechanism for Publisher Confirms and Returns
 
-When the connection factory is configured for publisher confirms and returns, the sections above discuss the configuration of message channels to receive the confirms and returns asynchronously.
-Starting with version 5.4, there is an additional mechanism which is generally easier to use.
+When the connection factory is configured for publisher confirms and returns, the sections above discuss the configuration of message channels to receive the `confirms` and `returns` asynchronously.
+Starting with version 5.4, there is an additional mechanism that is generally easier to use.
 
-In this case, do not configure a `confirm-correlation-expression` or the confirm and return channels.
+In this case, do not configure a `confirm-correlation-expression` or the `confirm` and `return` channels.
 Instead, add a `CorrelationData` instance in the `AmqpHeaders.PUBLISH_CONFIRM_CORRELATION` header; you can then wait for the result(s) later, by checking the state of the future in the `CorrelationData` instances for which you have sent messages.
 The `returnedMessage` field will always be populated (if a message is returned) before the future is completed.
 
@@ -27,5 +27,5 @@ catch { ... }
 ----
 
 To improve performance, you may wish to send multiple messages and wait for the confirmations later, rather than one-at-a-time.
-The returned message is the raw message after conversion; you can sub-class a `CorrelationData` with whatever additional data you need.
+The returned message is the raw message after conversion; you can subclass a `CorrelationData` with whatever additional data you need.
 

src/reference/antora/modules/ROOT/pages/amqp/alternative-confirms-returns.adoc

@@ -128,9 +128,9 @@ By default, this is an empty `String`.
 Mutually exclusive with 'routing-key-expression'.
 Optional.
 <11> A SpEL expression that is evaluated to determine the routing-key to use when sending messages,
-with the message as the root object (for example, 'payload.key').
+with the message as the root object, (for example, `payload.key`).
 By default, this is an empty `String`.
-Mutually exclusive with 'routing-key'.
+Mutually exclusive with `routing-key`.
 Optional.
 <12> The default delivery mode for messages: `PERSISTENT` or `NON_PERSISTENT`.
 Overridden if the `header-mapper` sets the delivery mode.
@@ -170,7 +170,7 @@ Requires the underlying `AsyncRabbitTemplate` to have its `mandatory` property s
 Also see xref:amqp/alternative-confirms-returns.adoc[Alternative Mechanism for Publisher Confirms and Returns].
 Optional.
 <18> When set to `false`, the endpoint tries to connect to the broker during application context initialization.
-Doing so allows "`fail fast`" detection of bad configuration, by logging an error message if the broker is down.
+Doing so allows "`fail fast`" detection of bad configuration by logging an error message if the broker is down.
 When `true` (the default), the connection is established (if it does not already exist because some other component established
 it) when the first message is sent.
 

src/reference/antora/modules/ROOT/pages/amqp/async-outbound-gateway.adoc

@@ -2,9 +2,8 @@
 = AMQP-backed Message Channels
 
 There are two message channel implementations available.
-One is point-to-point, and the other is publish-subscribe.
-Both of these channels provide a wide range of configuration attributes for the underlying `AmqpTemplate` and
-`SimpleMessageListenerContainer` (as shown earlier in this chapter for the channel adapters and gateways).
+One is `point-to-point`, and the other is `publish-subscribe`.
+Both of these channels provide a wide range of configuration attributes for the underlying `AmqpTemplate` and `SimpleMessageListenerContainer` (as shown earlier in this chapter for the channel adapters and gateways).
 However, the examples we show here have minimal configuration.
 Explore the XML schema to view the available attributes.
 
@@ -43,7 +42,7 @@ Note that, previously, `channel-transacted` was `true` by default.
 Now, by default, it is `false` for the `AbstractMessageListenerContainer`.
 
 Prior to version 4.3, AMQP-backed channels only supported messages with `Serializable` payloads and headers.
-The entire message was converted (serialized) and sent to RabbitMQ.
+The entire message was converted, (serialized) and sent to RabbitMQ.
 Now, you can set the `extract-payload` attribute (or `setExtractPayload()` when using Java configuration) to `true`.
 When this flag is `true`, the message payload is converted and the headers are mapped, in a manner similar to when you use channel adapters.
 This arrangement lets AMQP-backed channels be used with non-serializable payloads (perhaps with another message converter, such as the `Jackson2JsonMessageConverter`).

src/reference/antora/modules/ROOT/pages/amqp/channels.adoc

@@ -52,6 +52,6 @@ There is now a property called `headersMappedLast` on the outbound channel adapt
 Setting this to `true` restores the behavior of overwriting the property added by the converter.
 
 Starting with version 5.1.9, a similar `replyHeadersMappedLast` is provided for the `AmqpInboundGateway` when we produce a reply and would like to override headers populated by the converter.
-See its JavaDocs for more information.
+See its Javadocs for more information.
 ====
 

src/reference/antora/modules/ROOT/pages/amqp/content-type-conversion-outbound.adoc

@@ -6,7 +6,7 @@ Inbound messages, arriving at the channel adapter or gateway, are converted to t
 By default, a `SimpleMessageConverter` is used, which handles java serialization and text.
 Headers are mapped using the `DefaultHeaderMapper.inboundMapper()` by default.
 If a conversion error occurs, and there is no error channel defined, the exception is thrown to the container and handled by the listener container's error handler.
-The default error handler treats conversion errors as fatal and the message will be rejected (and routed to a dead-letter exchange, if the queue is so configured).
+The default error handler treats conversion errors as fatal, and the message will be rejected (and routed to a dead-letter exchange if the queue is so configured).
 If an error channel is defined, the `ErrorMessage` payload is a `ListenerExecutionFailedException` with properties `failedMessage` (the Spring AMQP message that could not be converted) and the `cause`.
 If the container `AcknowledgeMode` is `AUTO` (the default) and the error flow consumes the error without throwing an exception, the original message will be acknowledged.
 If the error flow throws an exception, the exception type, in conjunction with the container's error handler, will determine whether the message is requeued.

src/reference/antora/modules/ROOT/pages/amqp/conversion-inbound.adoc

@@ -90,7 +90,8 @@ XML::
                                   batch-size=""                   <25>
                                   consumers-per-queue             <26>
                                   batch-mode="MESSAGES"/>         <27>
-
+----
+======
 <1> The unique ID for this adapter.
 Optional.
 <2> Message channel to which converted messages should be sent.
@@ -126,15 +127,15 @@ Optional (defaults to true).
 Optional.
 By default, only standard AMQP properties (such as `contentType`) are copied to Spring Integration `MessageHeaders`.
 Any user-defined headers within the AMQP `MessageProperties` are NOT copied to the message by the default `DefaultAmqpHeaderMapper`.
-Not allowed if 'request-header-names' is provided.
+Not allowed if `request-header-names` is provided.
 <12> Comma-separated list of the names of AMQP Headers to be mapped from the AMQP request into the `MessageHeaders`.
 This can only be provided if the 'header-mapper' reference is not provided.
 The values in this list can also be simple patterns to be matched against the header names (such as "\*" or "thing1*, thing2" or "*something").
 <13> Reference to the `AbstractMessageListenerContainer` to use for receiving AMQP Messages.
 If this attribute is provided, no other attribute related to the listener container configuration should be provided.
 In other words, by setting this reference, you must take full responsibility for the listener container configuration.
 The only exception is the `MessageListener` itself.
-Since that is actually the core responsibility of this channel adapter implementation, the referenced listener container must not already have its own `MessageListener`.
+Since that is actually the core responsibility of this channel adapter implementation, the referenced listener container must not yet have its own `MessageListener`.
 Optional.
 <14> The `MessageConverter` to use when receiving AMQP messages.
 Optional.
@@ -170,8 +171,7 @@ Optional (defaults to `DefaultTransactionAttribute`).
 The transaction manager works in conjunction with the `channel-transacted` attribute.
 If there is already a transaction in progress when the framework is sending or receiving a message and the `channelTransacted` flag is `true`, the commit or rollback of the messaging transaction is deferred until the end of the current transaction.
 If the `channelTransacted` flag is `false`, no transaction semantics apply to the messaging operation (it is auto-acked).
-For further information, see
-https://docs.spring.io/spring-amqp/reference/html/%255Freference.html#%5Ftransactions[Transactions with Spring AMQP].
+For further information, see https://docs.spring.io/spring-amqp/reference/html/%255Freference.html#%5Ftransactions[Transactions with Spring AMQP].
 Optional.
 <25> Tells the `SimpleMessageListenerContainer` how many messages to process in a single request.
 For best results, it should be less than or equal to the value set in `prefetch-count`.
@@ -183,8 +183,6 @@ See the https://docs.spring.io/spring-amqp/reference/html/[Spring AMQP Reference
 When set to `MESSAGES` (default), the payload is a `List<Message<?>>` where each message has headers mapped from the incoming AMQP `Message` and the payload is the converted `body`.
 When set to `EXTRACT_PAYLOADS`, the payload is a `List<?>` where the elements are converted from the AMQP `Message` body.
 `EXTRACT_PAYLOADS_WITH_HEADERS` is similar to `EXTRACT_PAYLOADS` but, in addition, the headers from each message are mapped from the `MessageProperties` into a `List<Map<String, Object>` at the corresponding index; the header name is `AmqpInboundChannelAdapter.CONSOLIDATED_HEADERS`.
-----
-======
 
 [NOTE]
 .container

src/reference/antora/modules/ROOT/pages/amqp/inbound-channel-adapter.adoc

@@ -1,7 +1,7 @@
 [[amqp-inbound-gateway]]
 = Inbound Gateway
 
-The inbound gateway supports all the attributes on the inbound channel adapter (except that 'channel' is replaced by 'request-channel'), plus some additional attributes.
+The inbound gateway supports all the attributes on the inbound channel adapter (except that `channel` is replaced by `request-channel`), plus some additional attributes.
 The following listing shows the available attributes:
 
 [tabs]

src/reference/antora/modules/ROOT/pages/amqp/inbound-gateway.adoc

@@ -72,7 +72,7 @@ Instead, this header is mapped to `amqp_receivedDeliveryMode`, which is not mapp
 Starting with version 4.3, patterns in the header mappings can be negated by preceding the pattern with `!`.
 Negated patterns get priority, so a list such as `STANDARD_REQUEST_HEADERS,thing1,ba*,!thing2,!thing3,qux,!thing1` does not map `thing1` (nor `thing2` nor `thing3`).
 The standard headers plus `bad` and `qux` are mapped.
-The negation technique can be useful for example to not map JSON type headers for incoming messages when a JSON deserialization logic is done in the receiver downstream different way.
+The negation technique can be useful, for example, to not map JSON type headers for incoming messages when a JSON deserialization logic is done in the receiver downstream a different way.
 For this purpose a `!json_*` pattern should be configured for header mapper of the inbound channel adapter/gateway.
 
 IMPORTANT: If you have a user-defined header that begins with `!` that you do wish to map, you need to escape it with `\`, as follows: `STANDARD_REQUEST_HEADERS,\!myBangHeader`.
@@ -86,12 +86,12 @@ It is useful to populate the `messageId` property when message consumers are usi
 == The `contentType` Header
 
 Unlike other headers, the `AmqpHeaders.CONTENT_TYPE` is not prefixed with `amqp_`; this allows transparent passing of the contentType header across different technologies.
-For example an inbound HTTP message sent to a RabbitMQ queue.
+For example, an inbound HTTP message sent to a RabbitMQ queue.
 
-The `contentType` header is mapped to Spring AMQP's `MessageProperties.contentType` property and that is subsequently mapped to RabbitMQ's `content_type` property.
+The `contentType` header is mapped to Spring AMQP's `MessageProperties.contentType` property and that is subsequently mapped to RabbitMQ `content_type` property.
 
 Prior to version 5.1, this header was also mapped as an entry in the `MessageProperties.headers` map; this was incorrect and, furthermore, the value could be wrong since the underlying Spring AMQP message converter might have changed the content type.
 Such a change would be reflected in the first-class `content_type` property, but not in the RabbitMQ headers map.
-Inbound mapping ignored the headers map value.
-`contentType` is no longer mapped to an entry in the headers map.
+Inbound mapping ignored the header map value.
+`contentType` is no longer mapped to an entry in the header map.