HHH-10765 Some links in the user guide are broken

HHH-10522 Invalid reference to naming chapter in user guide
HHH-10524 Invalid reference wrt composite identifiers
HHH-10525 Invalid reference to bytecode enhancement in User Guide

documentation/src/main/asciidoc/userguide/chapters/caching/Caching.adoc

@@ -533,11 +533,12 @@ Traditionally the `transactional` and `read-only` strategy was supported on _tra
 
 * _non-transactional invalidation_ caches are supported as well with `read-write` strategy. The actual setting of cache concurrency mode (`read-write` vs. `transactional`) is not honored, the appropriate strategy is selected based on the cache configuration (_non-transactional_ vs. _transactional_).
 * `read-write` mode is supported on _non-transactional distributed/replicated_ caches, however, eviction should not be used in this configuration. Use of eviction can lead to consistency issues. Expiration (with reasonably long max-idle times) can be used.
-* `nonstrict-read-write` mode is supported on _non-transactional distributed/replicated_ caches, but the eviction should be turned off as well. In addition to that, the entities must use versioning. This mode mildly relaxes the consistency - between DB commit and end of transaction commit a stale read (see <<cache-provider-infinispan-stale-read-example,example>>) may occur in another transaction. However this strategy uses less RPCs and can be more performant than the other ones.
+* `nonstrict-read-write` mode is supported on _non-transactional distributed/replicated_ caches, but the eviction should be turned off as well. In addition to that, the entities must use versioning. This mode mildly relaxes the consistency - between DB commit and end of transaction commit a stale read (see <<caching-provider-infinispan-stale-read-example,example>>) may occur in another transaction. However this strategy uses less RPCs and can be more performant than the other ones.
 * `read-only` mode is supported on both _transactional_ and _non-transactional_ _invalidation_ caches and _non-transactional distributed/replicated_ caches, but use of this mode currently does not bring any performance gains.
 
-The available combinations are summarized in table below
-[[cache-provider-infinispan-compatibility-table]]
+The available combinations are summarized in table below:
+
+[[caching-provider-infinispan-compatibility-table]]
 .Cache concurrency strategy/cache mode compatibility table
 [options="header"]
 |===

documentation/src/main/asciidoc/userguide/chapters/domain/basic_types.adoc

@@ -157,13 +157,13 @@ As long as the type is not primitive, Hibernate takes this to mean that the unde
 `fetch` - FetchType (defaults to EAGER):: Defines whether this attribute should be fetched eagerly or lazily.
 JPA says that EAGER is a requirement to the provider (Hibernate) that the value should be fetched when the owner is fetched, while LAZY is merely a hint that the value be fetched when the attribute is accessed.
 Hibernate ignores this setting for basic types unless you are using bytecode enhancement.
-See the <chapters/pc/BytecodeEnhancement.adoc#BytecodeEnhancement,BytecodeEnhancement>> for additional information on fetching and on bytecode enhancement.
+See the <<chapters/pc/BytecodeEnhancement.adoc#BytecodeEnhancement,BytecodeEnhancement>> for additional information on fetching and on bytecode enhancement.
 
 [[basic-column-annotation]]
 ==== The `@Column` annotation
 
 JPA defines rules for implicitly determining the name of tables and columns.
-For a detailed discussion of implicit naming see <<naming.adoc#naming,Naming>>.
+For a detailed discussion of implicit naming see <<chapters/domain/naming.adoc#naming,Naming>>.
 
 For basic type attributes, the implicit naming rule is that the column name is the same as the attribute name.
 If that implicit naming rule does not meet your requirements, you can explicitly tell Hibernate (and other providers) the column name to use.

documentation/src/main/asciidoc/userguide/chapters/domain/dynamic_model.adoc

@@ -15,12 +15,6 @@ Persistent entities do not necessarily have to be represented as POJO/JavaBean c
 Hibernate also supports dynamic models (using `Map`s of `Map`s at runtime).
 With this approach, you do not write persistent classes, only mapping files.
 
-[NOTE]
-====
-The mapping of dynamic models is beyond the scope of this chapter.
-We will discuss using such models with Hibernate, in the <<mapping, next chapter>>.
-====
-
 A given entity has just one entity mode within a given SessionFactory.
 This is a change from previous versions which allowed to define multiple entity modes for an entity and to select which to load.
 Entity modes can now be mixed within a domain model; a dynamic entity might reference a POJO entity, and vice versa.

documentation/src/main/asciidoc/userguide/chapters/domain/embeddables.adoc

@@ -119,7 +119,7 @@ This is a Hibernate specific feature.
 Users concerned with JPA provider portability should instead prefer explicit column naming with <<embeddable-multiple-jpa,`@AttributeOverride`>>.
 ====
 
-Hibernate naming strategies are covered in detail in <<naming.adoc#naming,Naming>>.
+Hibernate naming strategies are covered in detail in <<chapters/domain/naming.adoc#naming,Naming>>.
 However, for the purposes of this discussion, Hibernate has the capability to interpret implicit column names in a way that is safe for use with multiple embeddable types.
 
 .Enabling embeddable type safe implicit naming
@@ -144,19 +144,19 @@ You could even develop your own to do special implicit naming.
 ==== Collections of embeddable types
 
 Collections of embeddable types are specifically value collections (as embeddable types are a value type).
-Value collections are covered in detail in <<collection.adoc#collections-value,Collections of value types>>.
+Value collections are covered in detail in <<chapters/domain/collections.adoc#collections-value,Collections of value types>>.
 
 [[embeddable-mapkey]]
 ==== Embeddable types as Map key
 
 Embeddable types can also be used as `Map` keys.
-This topic is converted in detail in <<collection.adoc#collections-map,Map - key>>.
+This topic is converted in detail in <<chapters/domain/collections.adoc#collections-map,Map - key>>.
 
 [[embeddable-identifier]]
 ==== Embeddable types as identifiers
 
 Embeddable types can also be used as entity type identifiers.
-This usage is covered in detail in <chapters/domain/identifiers.adoc#identifiers-composite,Composite identifiers>>.
+This usage is covered in detail in <<chapters/domain/identifiers.adoc#identifiers-composite,Composite identifiers>>.
 
 [IMPORTANT]
 ====

documentation/src/main/asciidoc/userguide/chapters/domain/entity.adoc

@@ -52,7 +52,7 @@ For the very same reason, you should also avoid declaring persistent attribute g
 ====
 Starting in 5.0 Hibernate offers a more robust version of bytecode enhancement as another means for handling lazy loading.
 Hibernate had some bytecode re-writing capabilities prior to 5.0 but they were very rudimentary.
-See the <chapters/pc/BytecodeEnhancement.adoc#BytecodeEnhancement,BytecodeEnhancement>> for additional information on fetching and on bytecode enhancement.
+See the <<chapters/pc/BytecodeEnhancement.adoc#BytecodeEnhancement,BytecodeEnhancement>> for additional information on fetching and on bytecode enhancement.
 ====
 
 [[entity-pojo-constructor]]
@@ -257,7 +257,7 @@ include::{sourcedir}/entity/listing9.java[]
 
 As you can see the question of equals/hashCode is not trivial, nor is there a one-size-fits-all solution.
 
-For details on mapping the identifier, see the <<chapters/domain/identifiers.adoc#identiifers,Identifiers>> chapter.
+For details on mapping the identifier, see the <<chapters/domain/identifiers.adoc#identifiers,Identifiers>> chapter.
 
 [[entity-pojo-optlock]]
 ==== Mapping optimistic locking

documentation/src/main/asciidoc/userguide/chapters/domain/naming.adoc

@@ -76,7 +76,7 @@ the implementation using the `hibernate.implicit_naming_strategy` configuration
 
 Secondly, applications and integrations can leverage `org.hibernate.boot.MetadataBuilder#applyImplicitNamingStrategy`
 to specify the ImplicitNamingStrategy to use.  See
-<<chapters/bootstrap/Bootstrap.adoc#Bootstrap,Bootstrap>> for additional details on bootstrapping.
+<<chapters/bootstrap/Bootstrap.adoc#bootstrap,Bootstrap>> for additional details on bootstrapping.
 
 
 
@@ -123,7 +123,7 @@ the implementation using the `hibernate.physical_naming_strategy` configuration
 * FQN of a class that implements the `org.hibernate.boot.model.naming.PhysicalNamingStrategy` contract
 
 Secondly, applications and integrations can leverage `org.hibernate.boot.MetadataBuilder#applyPhysicalNamingStrategy`.
-See <<chapters/bootstrap/Bootstrap.adoc#Bootstrap,Bootstrap>> for additional details on bootstrapping.
+See <<chapters/bootstrap/Bootstrap.adoc#bootstrap,Bootstrap>> for additional details on bootstrapping.
 
 
 

documentation/src/main/asciidoc/userguide/chapters/domain/natural_id.adoc

@@ -62,7 +62,7 @@ If the entity is already associated with the current running Session, that refer
 If the entity is not loaded in the current Session and the entity supports proxy generation, an uninitialized proxy is generated and returned, otherwise the entity is loaded from the database and returned.
 
 `NaturalIdLoadAccess` allows loading an entity by natural id and at the same time apply a pessimistic lock.
-For additional details on locking, see the <<chapters/locking/locking.adoc#locking,Locking>> chapter.
+For additional details on locking, see the <<chapters/locking/Locking.adoc#locking,Locking>> chapter.
 
 We will discuss the last method available on NaturalIdLoadAccess ( `setSynchronizationEnabled()` ) in <<naturalid-mutability-caching>>.
 

documentation/src/main/asciidoc/userguide/chapters/domain/types.adoc

@@ -52,7 +52,7 @@ Value types are further classified into three sub-categories:
 
 Basic types:: in mapping the `Contact` table, all attributes except for name would be basic types. Basic types are discussed in detail in <<chapters/domain/basic_types.adoc#basic,_Basic Types_>>
 Embeddable types:: the name attribute is an example of an embeddable type, which is discussed in details in <<chapters/domain/embeddables.adoc#embeddables,_Embeddable Types_>>
-Collection types:: although not featured in the aforementioned example, collection types are also a distinct category among value types. Collection types are further discussed in <<chapters/domain/collection.adoc#collections,_Collections_>>
+Collection types:: although not featured in the aforementioned example, collection types are also a distinct category among value types. Collection types are further discussed in <<chapters/domain/collections.adoc#collections,_Collections_>>
 
 [[categorization-entity]]
 ==== Entity types

documentation/src/main/asciidoc/userguide/chapters/pc/PersistenceContext.adoc

@@ -201,7 +201,7 @@ load::
 	Will return the persistent data associated with the given identifier value or null if that identifier does not exist.
 
 Each of these two methods define an overloading variant accepting a `org.hibernate.LockOptions` argument.
-Locking is discussed in a separate <<chapters/locking/locking.adoc#locking,chapter>>.
+Locking is discussed in a separate <<chapters/locking/Locking.adoc#locking,chapter>>.
 
 [[pc-managed-state]]
 === Modifying managed/persistent state

documentation/src/main/asciidoc/userguide/chapters/query/hql/HQL.adoc

@@ -962,7 +962,7 @@ include::{sourcedir}/HQLTest.java[tags=hql-aggregate-functions-example]
 ----
 ====
 
-Aggregations often appear with grouping. For information on grouping see <<hql-grouping>>.
+Aggregations often appear with grouping. For information on grouping see <<hql-group-by>>.
 
 [[hql-exp-functions]]
 === Scalar functions
@@ -1126,7 +1126,7 @@ include::{sourcedir}/HQLTest.java[tags=hql-bit-length-function-example]
 CAST::
 	Performs a SQL cast.
 	The cast target should name the Hibernate mapping type to use.
-	See the <<chapters/domain/basic_types.adoc#[basic-provided,data types>> chapter on for more information.
+	See the <<chapters/domain/basic_types.adoc#basic-provided,data types>> chapter on for more information.
 
 ====
 [source, JAVA, indent=0]