Removed the troublesome backticks

Removed the backticks that were making links not render. Fixed a few typoes, too.

Integrating feedback from Artem

Artem caught some errors that I had made (and that my editor, Atom, had made - grrr). I fixed them.

Thanks, Artem. :)

Removing duplicate content

I caught that duplicate content somehow got added to preface.adoc. I removed one set of it to make that content not be duplicated.

* Fix `jdbc.adoc` typos

Author: Jay Bryant

src/reference/asciidoc/aggregator.adoc

@@ -97,7 +97,7 @@ However, there are better solutions, less coupled to the API, for implementing t
 In general, any POJO can implement the aggregation algorithm if it provides a method that accepts a single `java.util.List` as an argument (parameterized lists are supported as well).
 This method is invoked for aggregating messages as follows:
 
-* If the argument is a `java.util.Collection<T>`, and the parameter type T is assignable to `Message`, the whole list of messages accumulated for aggregation is sent to the aggregator.
+* If the argument is a `java.util.Collection<T>` and the parameter type T is assignable to `Message`, the whole list of messages accumulated for aggregation is sent to the aggregator.
 * If the argument is a non-parameterized `java.util.Collection` or the parameter type is not assignable to `Message`, the method receives the payloads of the accumulated messages.
 * If the return type is not assignable to `Message`, it is treated as the payload for a `Message` that is automatically created by the framework.
 
@@ -142,7 +142,7 @@ public interface ReleaseStrategy {
 In general, any POJO can implement the completion decision logic if it provides a method that accepts a single `java.util.List` as an argument (parameterized lists are supported as well) and returns a boolean value.
 This method is invoked after the arrival of each new message, to decide whether the group is complete or not, as follows:
 
-* If the argument is a `java.util.List<T>`, and the parameter type `T` is assignable to `Message`, the whole list of messages accumulated in the group is sent to the method.
+* If the argument is a `java.util.List<T>` and the parameter type `T` is assignable to `Message`, the whole list of messages accumulated in the group is sent to the method.
 * If the argument is a non-parametrized `java.util.List` or the parameter type is not assignable to `Message`, the method receives the payloads of the accumulated messages.
 * The method must return `true` if the message group is ready for aggregation or false otherwise.
 
@@ -197,7 +197,7 @@ IMPORTANT: To facilitate discarding of late-arriving messages, the aggregator mu
 This can eventually cause out-of-memory conditions.
 To avoid such situations, you should consider configuring a `MessageGroupStoreReaper` to remove the group metadata.
 The expiry parameters should be set to expire groups once a point has been reach after after which late messages are not expected to arrive.
-For information about configuring a reaper, see "`<<reaper>>`".
+For information about configuring a reaper, see <<reaper>>.
 
 Spring Integration provides an implementation for `ReleaseStrategy`: `SimpleSequenceSizeReleaseStrategy`.
 This implementation consults the `SEQUENCE_NUMBER` and `SEQUENCE_SIZE` headers of each arriving message to decide when a message group is complete and ready to be aggregated.
@@ -215,7 +215,7 @@ The 4.3 release changed the default `Collection` for messages in a `SimpleMessag
 This was expensive when removing individual messages from large groups (an O(n) linear scan was required).
 Although the hash set is generally much faster to remove, it can be expensive for large messages, because the hash has to be calculated on both inserts and removes.
 If you have messages that are expensive to hash, consider using some other collection type.
-As discussed in "`<<message-group-factory>>`", a `SimpleMessageGroupFactory` is provided so that you can select the `Collection` that best suits your needs.
+As discussed in <<message-group-factory>>, a `SimpleMessageGroupFactory` is provided so that you can select the `Collection` that best suits your needs.
 You can also provide your own factory implementation to create some other `Collection<Message<?>>`.
 
 The following example shows how to configure an aggregator with the previous implementation and a `SimpleSequenceSizeReleaseStrategy`:
@@ -269,12 +269,12 @@ If you have a custom header name you would like to use for correlation, you can
 Changes to groups are thread safe.
 A `LockRegistry` is used to obtain a lock for the resolved correlation ID.
 A `DefaultLockRegistry` is used by default (in-memory).
-For synchronizing updates across servers, where a shared `MessageGroupStore` is being used, you must configure a shared lock registry.
+For synchronizing updates across servers where a shared `MessageGroupStore` is being used, you must configure a shared lock registry.
 
 [[aggregator-java-dsl]]
 ==== Configuring an Aggregator in Java DSL
 
-See "`<<java-dsl-aggregators>>`" for how to configure an aggregator in Java DSL.
+See <<java-dsl-aggregators>> for how to configure an aggregator in Java DSL.
 
 [[aggregator-xml]]
 ===== Configuring an Aggregator with XML
@@ -349,7 +349,7 @@ Optional.
 <6> A reference to a `MessageGroupStore` used to store groups of messages under their correlation key until they are complete.
 Optional.
 By default, it is a volatile in-memory store.
-See "`<<message-store>>`" for more information.
+See <<message-store>> for more information.
 <7> The order of this aggregator when more than one handle is subscribed to the same `DirectChannel` (use for load-balancing purposes).
 Optional.
 <8> Indicates that expired messages should be aggregated and sent to the 'output-channel' or 'replyChannel' once their containing `MessageGroup` is expired (see https://docs.spring.io/spring-integration/api/org/springframework/integration/store/MessageGroupStore.html#expireMessageGroups-long[`MessageGroupStore.expireMessageGroups(long)`]).
@@ -407,7 +407,7 @@ Note that the actual time to expire an empty group is also affected by the reape
 It used to obtain a `Lock` based on the `groupId` for concurrent operations on the `MessageGroup`.
 By default, an internal `DefaultLockRegistry` is used.
 Use of a distributed `LockRegistry`, such as the `ZookeeperLockRegistry`, ensures only one instance of the aggregator can operate on a group concurrently.
-See "`<<redis-lock-registry>>`", "`<<gemfire-lock-registry>>`", and "`<<zk-lock-registry>>`" for more information.
+See <<redis-lock-registry>>, <<gemfire-lock-registry>>, and <<zk-lock-registry>> for more information.
 <21> A timeout (in milliseconds) to force the `MessageGroup` complete when the `ReleaseStrategy` does not release the group when the current message arrives.
 This attribute provides a built-in time-based release strategy for the aggregator when there is a need to emit a partial result (or discard the group) if a new message does not arrive for the `MessageGroup` within the timeout.
 When a new message arrives at the aggregator, any existing `ScheduledFuture<?>` for its `MessageGroup` is canceled.
@@ -417,7 +417,7 @@ Doing so effectively disables the aggregator, because every message group is imm
 You can, however, conditionally set it to zero (or a negative value) by using an expression.
 See `group-timeout-expression` for information.
 The action taken during the completion depends on the `ReleaseStrategy` and the `send-partial-group-on-expiry` attribute.
-See "`<<agg-and-group-to>>`" for more information.
+See <<agg-and-group-to>> for more information.
 It is mutually exclusive with 'group-timeout-expression' attribute.
 <22> The SpEL expression that evaluates to a `groupTimeout` with the `MessageGroup` as the `#root` evaluation context object.
 Used for scheduling the `MessageGroup` to be forced complete.
@@ -610,7 +610,7 @@ In the preceding example, the root object of the SpEL evaluation context is the
 ====== Aggregator and Group Timeout
 
 Starting with version 4.0, two new mutually exclusive attributes have been introduced: `group-timeout` and `group-timeout-expression` (see the earlier description).
-See "`<<aggregator-xml>>`".
+See <<aggregator-xml>>.
 In some cases, you may need to emit the aggregator result (or discard the group) after a timeout if the `ReleaseStrategy` does not release when the current message arrives.
 For this purpose, the `groupTimeout` option lets scheduling the `MessageGroup` be forced to complete, as the following example shows:
 
@@ -634,7 +634,7 @@ If the release strategy still does not release the group, it is expired.
 If `send-partial-result-on-expiry` is `true`, existing messages in the (partial) `MessageGroup` are released as a normal aggregator reply message to the `output-channel`.
 Otherwise, it is discarded.
 
-There is a difference between `groupTimeout` behavior and `MessageGroupStoreReaper` (see "`<<aggregator-xml>>`").
+There is a difference between `groupTimeout` behavior and `MessageGroupStoreReaper` (see <<aggregator-xml>>).
 The reaper initiates forced completion for all `MessageGroup` s in the `MessageGroupStore` periodically.
 The `groupTimeout` does it for each `MessageGroup` individually if a new message does not arrive during the `groupTimeout`.
 Also, the reaper can be used to remove empty groups (empty groups are retained in order to discard late messages if `expire-groups-upon-completion` is false).
@@ -699,7 +699,7 @@ public MessageHandler aggregator(MessageGroupStore jdbcMessageGroupStore) {
 ----
 ====
 
-See "`<<aggregator-api>>`" and "`<<annotations_on_beans>>`" for more information.
+See <<aggregator-api>> and <<annotations_on_beans>> for more information.
 
 NOTE: Starting with version 4.2, the `AggregatorFactoryBean` is available to simplify Java configuration for the `AggregatingMessageHandler`.
 
@@ -761,7 +761,7 @@ public interface MessageGroupCallback {
 The callback has direct access to the store and the message group so that it can manage the persistent state (for example, by entirely removing the group from the store).
 
 The `MessageGroupStore` maintains a list of these callbacks, which it applies, on demand, to all messages whose timestamps are earlier than a time supplied as a parameter (see the `registerMessageGroupExpiryCallback(..)` and `expireMessageGroups(..)` methods, described earlier).
-For more detail, see "`<<reaper>>`".
+For more detail, see <<reaper>>.
 
 You can call the `expireMessageGroups` method with a timeout value.
 Any message older than the current time minus this value is expired and has the callbacks applied.
@@ -805,5 +805,5 @@ Messages with the same correlation key are stored in the same message group.
 Some `MessageStore` implementations allow using the same physical resources, by partitioning the data.
 For example, the `JdbcMessageStore` has a `region` property, and the `MongoDbMessageStore` has a `collectionName` property.
 
-For more information about the `MessageStore` interface and its implementations, see "`<<message-store>>`".
+For more information about the `MessageStore` interface and its implementations, see <<message-store>>.
 =====

src/reference/asciidoc/amqp.adoc

@@ -71,7 +71,7 @@ The user application is responsible for acknowledgement.
 `NONE` means no acknowledgements (`autoAck`).
 `AUTO` means the adapter's container acknowledges when the downstream flow completes.
 Optional (defaults to AUTO).
-See "`<<amqp-inbound-ack>>`".
+See <<amqp-inbound-ack>>.
 <5> Extra AOP Advices to handle cross-cutting behavior associated with this inbound channel adapter.
 Optional.
 <6> Flag to indicate that channels created by this component are transactional.
@@ -260,7 +260,7 @@ public class AmqpJavaApplication {
 === Polled Inbound Channel Adapter
 
 Version 5.0.1 introduced a polled channel adapter, letting you fetch individual messages on demand -- for example, with a `MessageSourcePollingTemplate` or a poller.
-See "`<<deferred-acks-message-source>>`" for more information.
+See <<deferred-acks-message-source>> for more information.
 
 It does not currently support XML configuration.
 
@@ -347,7 +347,7 @@ If this option is not specified and an external `amqp-template` is provided, no
 You must either specify this option or configure a default `exchange` and `routingKey` on that template,
 if you anticipate cases when no `replyTo` property exists in the request message.
 
-See the note in "`<<amqp-inbound-channel-adapter>>`" about configuring the `listener-container` attribute.
+See the note in <<amqp-inbound-channel-adapter>> about configuring the `listener-container` attribute.
 
 ==== Configuring with Java Configuration
 
@@ -974,7 +974,7 @@ When `true` (the default), the connection is established (if it does not already
 it) when the first message is sent.
 ====
 
-See also "`<<async-service-activator>>`" for more information.
+See also <<async-service-activator>> for more information.
 
 [IMPORTANT]
 .RabbitTemplate
@@ -1194,7 +1194,7 @@ 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`).
-See "`<<amqp-message-headers>>`" for more about the default mapped headers.
+See <<amqp-message-headers>> for more about the default mapped headers.
 You can modify the mapping by providing custom mappers that use the `outbound-header-mapper` and `inbound-header-mapper` attributes.
 You can now also specify a `default-delivery-mode`, which is used to set the delivery mode when there is no `amqp_deliveryMode` header.
 By default, Spring AMQP `MessageProperties` uses `PERSISTENT` delivery mode.
@@ -1314,7 +1314,7 @@ The `org.springframework.amqp.support.AmqpHeaders` class identifies the default
 * `amqp_clusterId`
 * `amqp_contentEncoding`
 * `amqp_contentLength`
-* `content-type` (see "`<<amqp-content-type>>`")
+* `content-type` (see <<amqp-content-type>>)
 * `amqp_correlationId`
 * `amqp_delay`
 * `amqp_deliveryMode`
@@ -1418,7 +1418,7 @@ This is because the template "`borrows`" a channel from the cache for each send
 One solution is to start a transaction before the splitter, but transactions are expensive in RabbitMQ and can reduce performance several hundred fold.
 
 To solve this problem in a more efficient manner, starting with version 5.1, Spring Integration provides the `BoundRabbitChannelAdvice` which is a `HandleMessageAdvice`.
-See "`<<handle-message-advice>>`".
+See <<handle-message-advice>>.
 When applied before the splitter, it ensures that all downstream operations are performed on the same channel and, optionally, can wait until publisher confirmations for all sent messages are received (if the connection factory is configured for confirmations).
 The following example shows how to use `BoundRabbitChannelAdvice`: