Fix broken cross-references in reference manual

src/asciidoc/core-aop.adoc

@@ -185,13 +185,13 @@ style.
 Spring AOP defaults to using standard JDK __dynamic proxies__ for AOP proxies. This
 enables any interface (or set of interfaces) to be proxied.
 
-Spring AOP can also use CGLIB proxies. This is necessary to proxy classes, rather than
+Spring AOP can also use CGLIB proxies. This is necessary to proxy classes rather than
 interfaces. CGLIB is used by default if a business object does not implement an
-interface. As it is good practice to program to interfaces rather than classes, business
+interface. As it is good practice to program to interfaces rather than classes; business
 classes normally will implement one or more business interfaces. It is possible to
-<<aop-autoproxy-force-CGLIB,force the use of CGLIB>>, in those (hopefully rare) cases
-where you need to advise a method that is not declared on an interface, or where you
-need to pass a proxied object to a method as a concrete type.
+<<aop-proxying,force the use of CGLIB>>, in those (hopefully rare) cases where you
+need to advise a method that is not declared on an interface, or where you need to
+pass a proxied object to a method as a concrete type.
 
 It is important to grasp the fact that Spring AOP is __proxy-based__. See
 <<aop-understanding-aop-proxies>> for a thorough examination of exactly what this
@@ -259,8 +259,8 @@ element:
 	<aop:aspectj-autoproxy/>
 ----
 
-This assumes that you are using schema support as described in <<xsd-config>>. See
-<<xsd-config-body-schemas-aop>> for how to import the tags in the aop namespace.
+This assumes that you are using schema support as described in <<xsd-configuration>>. See
+<<xsd-config-body-schemas-aop>> for how to import the tags in the `aop` namespace.
 
 
 
@@ -1546,8 +1546,8 @@ the new __syntax__ and refer the reader to the discussion in the previous sectio
 of advice parameters.
 
 To use the aop namespace tags described in this section, you need to import the
-spring-aop schema as described in <<xsd-config>>. See <<xsd-config-body-schemas-aop>>
-for how to import the tags in the aop namespace.
+`spring-aop` schema as described in <<xsd-configuration>>. See <<xsd-config-body-schemas-aop>>
+for how to import the tags in the `aop` namespace.
 
 Within your Spring configurations, all aspect and advisor elements must be placed within
 an `<aop:config>` element (you can have more than one `<aop:config>` element in an

src/asciidoc/core-beans.adoc

@@ -1591,7 +1591,7 @@ The above configuration is equivalent to the following Java code:
 The p-namespace enables you to use the `bean` element's attributes, instead of nested
 `<property/>` elements, to describe your property values and/or collaborating beans.
 
-Spring supports extensible configuration formats <<xsd-config,with namespaces>>, which are
+Spring supports extensible configuration formats <<xsd-configuration,with namespaces>>, which are
 based on an XML Schema definition. The `beans` configuration format discussed in this
 chapter is defined in an XML Schema document. However, the p-namespace is not defined in
 an XSD file and exists only in the core of Spring.
@@ -2549,7 +2549,7 @@ understand the "why" as well as the "how" behind it.
 
 To create such a proxy, you insert a child `<aop:scoped-proxy/>` element into a scoped
 bean definition. See <<beans-factory-scopes-other-injection-proxies>> and
-<<xsd-config>>.) Why do definitions of beans scoped at the `request`, `session`,
+<<xsd-configuration>>.) Why do definitions of beans scoped at the `request`, `session`,
 `globalSession` and custom-scope levels require the `<aop:scoped-proxy/>` element ?
 Let's examine the following singleton bean definition and contrast it with what you need
 to define for the aforementioned scopes. (The following `userPreferences` bean
@@ -3493,7 +3493,7 @@ you write your own `BeanPostProcessor` you should consider implementing the `Ord
 interface too. For further details, consult the javadocs of the `BeanPostProcessor` and
 `Ordered` interfaces. See also the note below on
 <<beans-factory-programmatically-registering-beanpostprocessors, programmatic
-registration of `BeanPostProcessors`>>
+registration of `BeanPostProcessors`>>.
 
 [NOTE]
 ====
@@ -3537,11 +3537,11 @@ interface, clearly indicating the post-processor nature of that bean. Otherwise,
 Since a ++BeanPostProcessor++ needs to be instantiated early in order to apply to the
 initialization of other beans in the context, this early type detection is critical.
 
+
+[[beans-factory-programmatically-registering-beanpostprocessors]]
+.Programmatically registering BeanPostProcessors
 [NOTE]
 ====
-
-*Programmatically registering BeanPostProcessors*
-
 While the recommended approach for `BeanPostProcessor` registration is through
 `ApplicationContext` auto-detection (as described above), it is also possible to
 register them __programmatically__ against a `ConfigurableBeanFactory` using the
@@ -3554,11 +3554,9 @@ programmatically are always processed before those registered through auto-detec
 regardless of any explicit ordering.
 ====
 
+.BeanPostProcessors and AOP auto-proxying
 [NOTE]
 ====
-
-*BeanPostProcessors and AOP auto-proxying*
-
 Classes that implement the `BeanPostProcessor` interface are __special__ and are treated
 differently by the container. All `BeanPostProcessors` __and beans that they reference
 directly__ are instantiated on startup, as part of the special startup phase of the

src/asciidoc/data-access.adoc

@@ -306,7 +306,7 @@ infrastructure.
 [NOTE]
 ====
 The above definition of the `dataSource` bean uses the `<jndi-lookup/>` tag from the
-`jee` namespace. For more information on schema-based configuration, see <<xsd-config>>,
+`jee` namespace. For more information on schema-based configuration, see <<xsd-configuration>>,
 and for more information on the `<jee/>` tags see the section entitled
 <<xsd-config-body-schemas-jee>>.
 ====

src/asciidoc/integration.adoc

@@ -6172,26 +6172,27 @@ Spring distribution. In all likelihood, you shouldn't ever need to implement you
   This implementation does not reuse any threads, rather it starts up a new thread
   for each invocation. However, it does support a concurrency limit which will block
   any invocations that are over the limit until a slot has been freed up. If you
-  re looking for true pooling, keep scrolling further down the page.
+  are looking for true pooling, see the discussions of `SimpleThreadPoolTaskExecutor`
+  and `ThreadPoolTaskExecutor` below.
 * `SyncTaskExecutor`
   This implementation doesn't execute invocations asynchronously. Instead, each
   invocation takes place in the calling thread. It is primarily used in situations
   where multi-threading isn't necessary such as simple test cases.
 * `ConcurrentTaskExecutor`
   This implementation is an adapter for a `java.util.concurrent.Executor` object.
-  There is an alternative, `ThreadPoolTaskExecutor, that exposes the `Executor`
+  There is an alternative, `ThreadPoolTaskExecutor`, that exposes the `Executor`
   configuration parameters as bean properties. It is rare to need to use the
-  `ConcurrentTaskExecutor` but if the <<threadPoolTaskExecutor, `ThreadPoolTaskExecutor`>>
-  isn't flexible enough for your needs, the `ConcurrentTaskExecutor` is an alternative.
+  `ConcurrentTaskExecutor`, but if the `ThreadPoolTaskExecutor` isn't flexible
+  enough for your needs, the `ConcurrentTaskExecutor` is an alternative.
 * `SimpleThreadPoolTaskExecutor`
   This implementation is actually a subclass of Quartz's `SimpleThreadPool` which
   listens to Spring's lifecycle callbacks. This is typically used when you have a
   thread pool that may need to be shared by both Quartz and non-Quartz components.
 * `ThreadPoolTaskExecutor`
   This implementation is the most commonly used one. It exposes bean properties for
-  configuring a java.util.concurrent.ThreadPoolExecutor` and wraps it in a `TaskExecutor`.
+  configuring a `java.util.concurrent.ThreadPoolExecutor` and wraps it in a `TaskExecutor`.
   If you need to adapt to a different kind of `java.util.concurrent.Executor`, it is
-  recommended that you use a <<concurrentTaskExecutor, `ConcurrentTaskExecutor`>> instead.
+  recommended that you use a `ConcurrentTaskExecutor` instead.
 * `WorkManagerTaskExecutor`
 
 +
@@ -6204,11 +6205,10 @@ Application Server implementations.
 
 +
 
-This implementation uses the CommonJ WorkManager as its backing implementation and is
-the central convenience class for setting up a CommonJ WorkManager reference in a Spring
-context. Similar to the <<simpleThreadPoolTaskExecutor, `SimpleThreadPoolTaskExecutor`>>,
-this class implements the WorkManager interface and therefore can be used directly as a
-WorkManager as well.
+This implementation uses the CommonJ `WorkManager` as its backing implementation and is
+the central convenience class for setting up a CommonJ `WorkManager` reference in a Spring
+context. Similar to the `SimpleThreadPoolTaskExecutor`, this class implements the
+`WorkManager` interface and therefore can be used directly as a `WorkManager` as well.
 
 
 
@@ -7121,7 +7121,7 @@ container. Using the dynamic-language-backed beans with a plain `BeanFactory`
 implementation is supported, but you have to manage the plumbing of the Spring internals
 to do so.
 
-For more information on schema-based configuration, see <<xsd-config>>.
+For more information on schema-based configuration, see <<xsd-configuration>>.
 ====
 
 [source,xml,indent=0]

src/asciidoc/web-websocket.adoc

@@ -263,7 +263,7 @@ XML configuration equivalent:
 ----
 
 The above is for use in Spring MVC applications and should be included in the
-configuration of a <<mvc-serlvet,DispatcherServlet>>. However, Spring's WebSocket
+configuration of a <<mvc-servlet,DispatcherServlet>>. However, Spring's WebSocket
 support does not depend on Spring MVC. It is relatively simple to integrate a `WebSocketHandler`
 into other HTTP serving environments with the help of
 {javadoc-baseurl}/org/springframework/web/socket/server/support/WebSocketHttpRequestHandler.html[WebSocketHttpRequestHandler].
@@ -731,7 +731,7 @@ and the XML configuration equivalent:
 ----
 
 The above is for use in Spring MVC applications and should be included in the
-configuration of a <<mvc-serlvet,DispatcherServlet>>. However, Spring's WebSocket
+configuration of a <<mvc-servlet,DispatcherServlet>>. However, Spring's WebSocket
 and SockJS support does not depend on Spring MVC. It is relatively simple to
 integrate into other HTTP serving environments with the help of
 {javadoc-baseurl}/org/springframework/web/socket/sockjs/support/SockJsHttpRequestHandler.html[SockJsHttpRequestHandler].