Fix cross references

framework-docs/modules/ROOT/pages/data-access/orm/general.adoc

@@ -2,7 +2,7 @@
 = General ORM Integration Considerations
 
 This section highlights considerations that apply to all ORM technologies.
-The <<orm-hibernate>> section provides more details and also show these features and
+The xref:data-access/orm/hibernate.adoc[Hibernate] section provides more details and also show these features and
 configurations in a concrete context.
 
 The major goal of Spring's ORM integration is clear application layering (with any data
@@ -31,18 +31,18 @@ interceptors for the ORM technologies.
 The infrastructure provides proper resource handling and appropriate conversion of
 specific API exceptions to an unchecked infrastructure exception hierarchy. Spring
 introduces a DAO exception hierarchy, applicable to any data access strategy. For direct
-JDBC, the `JdbcTemplate` class mentioned in a <<jdbc-JdbcTemplate, previous section>>
+JDBC, the `JdbcTemplate` class mentioned in a xref:data-access/jdbc/core.adoc#jdbc-JdbcTemplate[previous section]
 provides connection handling and proper conversion of `SQLException` to the
 `DataAccessException` hierarchy, including translation of database-specific SQL error
 codes to meaningful exception classes. For ORM technologies, see the
-<<orm-exception-translation, next section>> for how to get the same exception
+xref:data-access/orm/general.adoc#orm-exception-translation[next section] for how to get the same exception
 translation benefits.
 
 When it comes to transaction management, the `JdbcTemplate` class hooks in to the Spring
 transaction support and supports both JTA and JDBC transactions, through respective
 Spring transaction managers. For the supported ORM technologies, Spring offers Hibernate
 and JPA support through the Hibernate and JPA transaction managers as well as JTA support.
-For details on transaction support, see the <<transaction>> chapter.
+For details on transaction support, see the xref:data-access/transaction.adoc[Transaction Management] chapter.
 
 
 [[orm-exception-translation]]

framework-docs/modules/ROOT/pages/data-access/orm/hibernate.adoc

@@ -21,7 +21,7 @@ To avoid tying application objects to hard-coded resource lookups, you can defin
 resources (such as a JDBC `DataSource` or a Hibernate `SessionFactory`) as beans in the
 Spring container. Application objects that need to access resources receive references
 to such predefined instances through bean references, as illustrated in the DAO
-definition in the <<orm-hibernate-straight, next section>>.
+definition in the xref:data-access/orm/hibernate.adoc#orm-hibernate-straight[next section].
 
 The following excerpt from an XML application context definition shows how to set up a
 JDBC `DataSource` and a Hibernate `SessionFactory` on top of it:
@@ -83,7 +83,7 @@ property. On the programmatic `LocalSessionFactoryBuilder`, there is an overload
 
 As of Spring Framework 5.1, such a native Hibernate setup can also expose a JPA
 `EntityManagerFactory` for standard JPA interaction next to native Hibernate access.
-See <<orm-jpa-hibernate, Native Hibernate Setup for JPA>> for details.
+See xref:data-access/orm/jpa.adoc#orm-jpa-hibernate[Native Hibernate Setup for JPA] for details.
 ====
 
 
@@ -185,7 +185,7 @@ container by using either Java annotations or XML. This declarative transaction
 lets you keep business services free of repetitive transaction demarcation code and
 focus on adding business logic, which is the real value of your application.
 
-NOTE: Before you continue, we are strongly encourage you to read <<transaction-declarative>>
+NOTE: Before you continue, we are strongly encourage you to read xref:data-access/transaction/declarative.adoc[Declarative Transaction Management]
 if you have not already done so.
 
 You can annotate the service layer with `@Transactional` annotations and instruct the
@@ -447,7 +447,7 @@ to which it synchronizes (along with Spring). You have two options for doing thi
 
 * Pass your Spring `JtaTransactionManager` bean to your Hibernate setup. The easiest
   way is a bean reference into the `jtaTransactionManager` property for your
-  `LocalSessionFactoryBean` bean (see <<transaction-strategies-hibernate>>).
+  `LocalSessionFactoryBean` bean (see xref:data-access/transaction/strategies.adoc#transaction-strategies-hibernate[Hibernate Transaction Setup]).
   Spring then makes the corresponding JTA strategies available to Hibernate.
 * You may also configure Hibernate's JTA-related properties explicitly, in particular
   "hibernate.transaction.coordinator_class", "hibernate.connection.handling_mode"

framework-docs/modules/ROOT/pages/data-access/orm/introduction.adoc

@@ -48,7 +48,7 @@ The benefits of using the Spring Framework to create your ORM DAOs include:
   aspect-oriented programming (AOP) style method interceptor either through the
   `@Transactional` annotation or by explicitly configuring the transaction AOP advice in
   an XML configuration file. In both cases, transaction semantics and exception handling
-  (rollback and so on) are handled for you. As discussed in <<orm-resource-mngmnt>>,
+  (rollback and so on) are handled for you. As discussed in xref:data-access/orm/general.adoc#orm-resource-mngmnt[Resource and Transaction Management],
   you can also swap various transaction managers, without affecting your ORM-related code.
   For example, you can swap between local transactions and JTA, with the same full services
   (such as declarative transactions) available in both scenarios. Additionally,

framework-docs/modules/ROOT/pages/data-access/orm/jpa.adoc

@@ -14,9 +14,9 @@ the underlying implementation in order to provide additional features.
 The Spring JPA support offers three ways of setting up the JPA `EntityManagerFactory`
 that is used by the application to obtain an entity manager.
 
-* <<orm-jpa-setup-lemfb>>
-* <<orm-jpa-setup-jndi>>
-* <<orm-jpa-setup-lcemfb>>
+* xref:data-access/orm/jpa.adoc#orm-jpa-setup-lemfb[Using `LocalEntityManagerFactoryBean`]
+* xref:data-access/orm/jpa.adoc#orm-jpa-setup-jndi[Obtaining an EntityManagerFactory from JNDI]
+* xref:data-access/orm/jpa.adoc#orm-jpa-setup-lcemfb[Using `LocalContainerEntityManagerFactoryBean`]
 
 [[orm-jpa-setup-lemfb]]
 === Using `LocalEntityManagerFactoryBean`
@@ -92,7 +92,7 @@ NOTE: If you want to specifically configure a Hibernate setup, an immediate alte
 is to set up a native Hibernate `LocalSessionFactoryBean` instead of a plain JPA
 `LocalContainerEntityManagerFactoryBean`, letting it interact with JPA access code
 as well as native Hibernate access code.
-See <<orm-jpa-hibernate, Native Hibernate setup for JPA interaction>> for details.
+See xref:data-access/orm/jpa.adoc#orm-jpa-hibernate[Native Hibernate setup for JPA interaction] for details.
 
 The `LocalContainerEntityManagerFactoryBean` gives full control over
 `EntityManagerFactory` configuration and is appropriate for environments where
@@ -172,11 +172,11 @@ Spring provides a number of `LoadTimeWeaver` implementations for various environ
 letting `ClassTransformer` instances be applied only for each class loader and not
 for each VM.
 
-See the <<core.adoc#aop-aj-ltw-spring, Spring configuration>> in the AOP chapter for
+See the xref:core/aop/using-aspectj.adoc#aop-aj-ltw-spring[Spring configuration] in the AOP chapter for
 more insight regarding the `LoadTimeWeaver` implementations and their setup, either
 generic or customized to various platforms (such as Tomcat, JBoss and WebSphere).
 
-As described in <<core.adoc#aop-aj-ltw-spring, Spring configuration>>, you can configure
+As described in xref:core/aop/using-aspectj.adoc#aop-aj-ltw-spring[Spring configuration], you can configure
 a context-wide `LoadTimeWeaver` by using the `@EnableLoadTimeWeaving` annotation or the
 `context:load-time-weaver` XML element. Such a global weaver is automatically picked up
 by all JPA `LocalContainerEntityManagerFactoryBean` instances. The following example
@@ -452,7 +452,7 @@ a non-invasiveness perspective and can feel more natural to JPA developers.
 [[orm-jpa-tx]]
 == Spring-driven JPA transactions
 
-NOTE: We strongly encourage you to read <<transaction-declarative>>, if you have not
+NOTE: We strongly encourage you to read xref:data-access/transaction/declarative.adoc[Declarative Transaction Management], if you have not
 already done so, to get more detailed coverage of Spring's declarative transaction support.
 
 The recommended strategy for JPA is local transactions through JPA's native transaction
@@ -464,12 +464,12 @@ Spring JPA also lets a configured `JpaTransactionManager` expose a JPA transacti
 to JDBC access code that accesses the same `DataSource`, provided that the registered
 `JpaDialect` supports retrieval of the underlying JDBC `Connection`.
 Spring provides dialects for the EclipseLink and Hibernate JPA implementations.
-See the <<orm-jpa-dialect, next section>> for details on the `JpaDialect` mechanism.
+See the xref:data-access/orm/jpa.adoc#orm-jpa-dialect[next section] for details on the `JpaDialect` mechanism.
 
 NOTE: As an immediate alternative, Spring's native `HibernateTransactionManager` is capable
 of interacting with JPA access code, adapting to several Hibernate specifics and providing
 JDBC interaction. This makes particular sense in combination with `LocalSessionFactoryBean`
-setup. See <<orm-jpa-hibernate, Native Hibernate Setup for JPA Interaction>> for details.
+setup. See xref:data-access/orm/jpa.adoc#orm-jpa-hibernate[Native Hibernate Setup for JPA Interaction] for details.
 
 
 [[orm-jpa-dialect]]
@@ -529,7 +529,7 @@ Hibernate 5.0 but not any more in Hibernate 5.1+. For a JTA setup, make sure to
 your persistence unit transaction type as "JTA". Alternatively, set Hibernate 5.2's
 `hibernate.connection.handling_mode` property to
 `DELAYED_ACQUISITION_AND_RELEASE_AFTER_STATEMENT` to restore Hibernate's own default.
-See <<orm-hibernate-invalid-jdbc-access-error>> for related notes.
+See xref:data-access/orm/hibernate.adoc#orm-hibernate-invalid-jdbc-access-error[Spurious Application Server Warnings with Hibernate] for related notes.
 
 * Alternatively, consider obtaining the `EntityManagerFactory` from your application
 server itself (that is, through a JNDI lookup instead of a locally declared
@@ -565,7 +565,7 @@ seamlessly integrating with `@Bean` style configuration (no `FactoryBean` involv
 ====
 `LocalSessionFactoryBean` and `LocalSessionFactoryBuilder` support background
 bootstrapping, just as the JPA `LocalContainerEntityManagerFactoryBean` does.
-See <<orm-jpa-setup-background, Background Bootstrapping>> for an introduction.
+See xref:data-access/orm/jpa.adoc#orm-jpa-setup-background[Background Bootstrapping] for an introduction.
 
 On `LocalSessionFactoryBean`, this is available through the `bootstrapExecutor`
 property. On the programmatic `LocalSessionFactoryBuilder`, an overloaded