Fix broken links in docs

src/reference/antora/modules/ROOT/pages/amqp/broker-configuration.adoc

@@ -45,7 +45,7 @@ See also xref:amqp/template.adoc#scoped-operations[Scoped Operations].
 The `getQueueProperties()` method returns some limited information about the queue (message count and consumer count).
 The keys for the properties returned are available as constants in the `RabbitTemplate` (`QUEUE_NAME`,
 `QUEUE_MESSAGE_COUNT`, and `QUEUE_CONSUMER_COUNT`).
-The <<management-rest-api, RabbitMQ REST API>> provides much more information in the `QueueInfo` object.
+The xref:amqp/management-rest-api.adoc#management-rest-api[RabbitMQ REST API] provides much more information in the `QueueInfo` object.
 
 The no-arg `declareQueue()` method defines a queue on the broker with a name that is automatically generated.
 The additional properties of this auto-generated queue are `exclusive=true`, `autoDelete=true`, and `durable=false`.

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

@@ -543,7 +543,7 @@ public RabbitTemplate rabbitTemplate() {
 }
 ----
 
-This way messages with the header `x-use-publisher-confirms: true` will be sent through the caching connection and you can ensure the message delivery.
+This way messages with the header `x-use-publisher-confirms: true` will be sent through the caching connection, and you can ensure the message delivery.
 See xref:amqp/connections.adoc#cf-pub-conf-ret[Publisher Confirms and Returns] for more information about ensuring message delivery.
 
 [[queue-affinity]]

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

@@ -144,7 +144,7 @@ a|
 
 |`m-n` The range of concurrent consumers for each listener (min, max).
 If only `n` is provided, `n` is a fixed number of consumers.
-See <<listener-concurrency>>.
+See xref:amqp/listener-concurrency.adoc#listener-concurrency[Listener Concurrency].
 
 a|image::tickmark.png[]
 a|
@@ -154,7 +154,7 @@ a|
 (concurrency)
 
 |The number of concurrent consumers to initially start for each listener.
-See <<listener-concurrency>>.
+See xref:amqp/listener-concurrency.adoc#listener-concurrency[Listener Concurrency].
 For the `StLC`, concurrency is controlled via an overloaded `superStream` method; see xref:stream.adoc#super-stream-consumer[Consuming Super Streams with Single Active Consumers].
 
 a|image::tickmark.png[]
@@ -176,7 +176,7 @@ a|
 
 |The minimum number of consecutive messages received by a consumer, without a receive timeout occurring, when considering starting a new consumer.
 Also impacted by 'batchSize'.
-See <<listener-concurrency>>.
+See xref:amqp/listener-concurrency.adoc#listener-concurrency[Listener Concurrency].
 Default: 10.
 
 a|image::tickmark.png[]
@@ -188,7 +188,7 @@ a|
 
 |The minimum number of receive timeouts a consumer must experience before considering stopping a consumer.
 Also impacted by 'batchSize'.
-See <<listener-concurrency>>.
+See xref:amqp/listener-concurrency.adoc#listener-concurrency[Listener Concurrency].
 Default: 10.
 
 a|image::tickmark.png[]
@@ -241,7 +241,7 @@ a|
 (consumers-per-queue)
 
 |The number of consumers to create for each configured queue.
-See <<listener-concurrency>>.
+See xref:amqp/listener-concurrency.adoc#listener-concurrency[Listener Concurrency].
 
 a|
 a|image::tickmark.png[]
@@ -409,7 +409,7 @@ a|
 
 |The maximum number of concurrent consumers to start, if needed, on demand.
 Must be greater than or equal to 'concurrentConsumers'.
-See <<listener-concurrency>>.
+See xref:amqp/listener-concurrency.adoc#listener-concurrency[Listener Concurrency].
 
 a|image::tickmark.png[]
 a|
@@ -663,7 +663,7 @@ a|
 (min-start-interval)
 
 |The time in milliseconds that must elapse before each new consumer is started on demand.
-See <<listener-concurrency>>.
+See xref:amqp/listener-concurrency.adoc#listener-concurrency[Listener Concurrency].
 Default: 10000 (10 seconds).
 
 a|image::tickmark.png[]
@@ -686,7 +686,7 @@ a|
 (min-stop-interval)
 
 |The time in milliseconds that must elapse before a consumer is stopped since the last consumer was stopped when an idle consumer is detected.
-See <<listener-concurrency>>.
+See xref:amqp/listener-concurrency.adoc#listener-concurrency[Listener Concurrency].
 Default: 60000 (one minute).
 
 a|image::tickmark.png[]

src/reference/antora/modules/ROOT/pages/amqp/multi-rabbit.adoc

@@ -129,7 +129,7 @@ By naming the `RabbitAdmin` beans with the convention `<container-factory-name>-
 This will also work with `bindings = @QueueBinding(...)` whereby the exchange and binding will also be declared.
 It will NOT work with `queues`, since that expects the queue(s) to already exist.
 
-On the producer side, a convenient `ConnectionFactoryContextWrapper` class is provided, to make using the `RoutingConnectionFactory` (see <<routing-connection-factory>>) simpler.
+On the producer side, a convenient `ConnectionFactoryContextWrapper` class is provided, to make using the `RoutingConnectionFactory` (see xref:amqp/connections.adoc#routing-connection-factory[Routing Connection Factory]) simpler.
 
 As you can see above, a `SimpleRoutingConnectionFactory` bean has been added with routing keys `one`, `two` and `three`.
 There is also a `RabbitTemplate` that uses that factory.

src/reference/antora/modules/ROOT/pages/amqp/receiving-messages/async-annotation-driven/container-management.adoc

@@ -18,6 +18,6 @@ This provides a mechanism to get a reference to a subset of containers.
 Adding a `group` attribute causes a bean of type `Collection<MessageListenerContainer>` to be registered with the context with the group name.
 
 By default, stopping a container will cancel the consumer and process all prefetched messages before stopping.
-Starting with versions 2.4.14, 3.0.6, you can set the <<forceStop>> container property to true to stop immediately after the current message is processed, causing any prefetched messages to be requeued.
+Starting with versions 2.4.14, 3.0.6, you can set the xref:amqp/containerAttributes.adoc#forceStop[`forceStop`] container property to true to stop immediately after the current message is processed, causing any prefetched messages to be requeued.
 This is useful, for example, if exclusive or single-active consumers are being used.
 

src/reference/antora/modules/ROOT/pages/amqp/receiving-messages/async-annotation-driven/conversion.adoc

@@ -60,7 +60,7 @@ method arguments.
 
 NOTE: This type inference works only for `@RabbitListener` at the method level.
 
-See <<json-message-converter>> for more information.
+See xref:amqp/message-converters.adoc#json-message-converter[`Jackson2JsonMessageConverter`] for more information.
 
 If you wish to customize the method argument converter, you can do so as follows:
 

src/reference/antora/modules/ROOT/pages/amqp/receiving-messages/async-consumer.adoc

@@ -237,7 +237,7 @@ For convenience, the namespace provides the `priority` attribute on the `listene
 ----
 
 Starting with version 1.3, you can modify the queues on which the container listens at runtime.
-See <<listener-queues>>.
+See xref:amqp/listener-queues.adoc#listener-queues[Listener Container Queues].
 
 [[lc-auto-delete]]
 == `auto-delete` Queues

src/reference/antora/modules/ROOT/pages/amqp/receiving-messages/consumer-events.adoc

@@ -22,7 +22,7 @@ A new method `logRestart()` has been added to the `ConditionalExceptionLogger` t
 
 Also, the `AbstractMessageListenerContainer.DefaultExclusiveConsumerLogger` is now public, allowing it to be sub classed.
 
-See also <<channel-close-logging>>.
+See also xref:amqp/connections.adoc#channel-close-logging[Logging Channel Close Events].
 
 Fatal errors are always logged at the `ERROR` level.
 This it not modifiable.

src/reference/antora/modules/ROOT/pages/amqp/receiving-messages/threading.adoc

@@ -24,5 +24,5 @@ IMPORTANT: With the `DirectMessageListenerContainer`, you need to ensure that th
 The default pool size (at the time of writing) is `Runtime.getRuntime().availableProcessors() * 2`.
 
 The `RabbitMQ client` uses a `ThreadFactory` to create threads for low-level I/O (socket) operations.
-To modify this factory, you need to configure the underlying RabbitMQ `ConnectionFactory`, as discussed in <<connection-factory>>.
+To modify this factory, you need to configure the underlying RabbitMQ `ConnectionFactory`, as discussed in xref:amqp/connections.adoc#connection-factory[Configuring the Underlying Client Connection Factory].
 

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

@@ -12,8 +12,8 @@ Currently, there is only a single implementation: `RabbitTemplate`.
 In the examples that follow, we often use an `AmqpTemplate`.
 However, when you look at the configuration examples or any code excerpts where the template is instantiated or setters are invoked, you can see the implementation type (for example, `RabbitTemplate`).
 
-As mentioned earlier, the `AmqpTemplate` interface defines all of the basic operations for sending and receiving messages.
-We will explore message sending and reception, respectively, in <<sending-messages>> and <<receiving-messages>>.
+As mentioned earlier, the `AmqpTemplate` interface defines all the basic operations for sending and receiving messages.
+We will explore message sending and reception, respectively, in xref:amqp/sending-messages.adoc#sending-messages[Sending Messages] and xref:amqp/receiving-messages.adoc#receiving-messages[Receiving Messages].
 
 See also xref:amqp/request-reply.adoc#async-template[Async Rabbit Template].