Add javadoc and fix typo

build.gradle

@@ -754,6 +754,7 @@ def generateAttributes() {
 'spring-retry-java-docs': "$springDocs/spring-retry/docs/$springRetryVersion/apidocs".toString(),
 'javadoc-location-org-springframework-transaction': "$springDocs/spring-framework/docs/$springVersion/javadoc-api".toString(),
 'javadoc-location-org-springframework-amqp': "$springDocs/spring-amqp/docs/$project.version/api".toString(),
+'javadoc-location-org-springframework-retry': "{spring-retry-java-docs}",
 'micrometer-docs': "$micrometerDocsPrefix/micrometer/reference/${generateVersionWithoutPatch(micrometerVersion)}".toString(),
 'micrometer-tracing-docs': "$micrometerDocsPrefix/tracing/reference/${generateVersionWithoutPatch(micrometerTracingVersion)}".toString()
 ]

src/reference/antora/modules/ROOT/pages/amqp/resilience-recovering-from-errors-and-broker-failures.adoc

@@ -55,7 +55,7 @@ You can do this manually, or you could look at using Spring Retry to handle the
 
 Spring Retry provides a couple of AOP interceptors and a great deal of flexibility to specify the parameters of the retry (number of attempts, exception types, backoff algorithm, and others).
 Spring AMQP also provides some convenience factory beans for creating Spring Retry interceptors in a convenient form for AMQP use cases, with strongly typed callback interfaces that you can use to implement custom recovery logic.
-See the Javadoc and properties of `StatefulRetryOperationsInterceptor` and `StatelessRetryOperationsInterceptor` for more detail.
+See the Javadoc and properties of javadoc:org.springframework.retry.interceptor.StatefulRetryOperationsInterceptor[] and javadoc:org.springframework.retry.interceptor.RetryOperationsInterceptor[] for more detail.
 Stateless retry is appropriate if there is no transaction or if a transaction is started inside the retry callback.
 Note that stateless retry is simpler to configure and analyze than stateful retry, but it is not usually appropriate if there is an ongoing transaction that must be rolled back or definitely is going to roll back.
 A dropped connection in the middle of a transaction should have the same effect as a rollback.

src/reference/antora/modules/ROOT/pages/appendix/previous-whats-new/changes-in-1-4-since-1-3.adoc

@@ -67,7 +67,7 @@ See xref:amqp/receiving-messages/async-consumer.adoc#lc-auto-delete[`auto-delete
 [[rabbittemplate:-mandatory-and-connectionfactoryselector-expressions]]
 == `RabbitTemplate`: `mandatory` and `connectionFactorySelector` Expressions
 
-The `mandatoryExpression`, `sendConnectionFactorySelectorExpression`, and `receiveConnectionFactorySelectorExpression` SpEL Expression`s properties have been added to `RabbitTemplate`.
+The `mandatoryExpression`, `sendConnectionFactorySelectorExpression`, and `receiveConnectionFactorySelectorExpression` SpEL Expression properties have been added to `RabbitTemplate`.
 The `mandatoryExpression` is used to evaluate a `mandatory` boolean value against each request message when a `ReturnCallback` is in use.
 See xref:amqp/template.adoc#template-confirms[Correlated Publisher Confirms and Returns].
 The `sendConnectionFactorySelectorExpression` and `receiveConnectionFactorySelectorExpression` are used when an `AbstractRoutingConnectionFactory` is provided, to determine the `lookupKey` for the target `ConnectionFactory` at runtime on each AMQP protocol interaction operation.