HHH-19827 Adjust image layout in the docs

Author: marko-bekhta

documentation/src/main/asciidoc/topical/registries/index.adoc

@@ -69,7 +69,7 @@ the Service (actually both a pull and a push/injection approach are supported).
 hierarchical, meaning a ServiceRegistry can have a parent ServiceRegistry.  Services in one registry can depend on
 and utilize services in that same registry as well as any parent registries.
 
-image::registry_hierarchy.jpg[ServiceRegistry UML]
+image::registry_hierarchy.jpg[ServiceRegistry UML,align="center"]
 
 
 == ServiceBinding

documentation/src/main/asciidoc/userguide/chapters/architecture/Architecture.adoc

@@ -4,7 +4,7 @@
 [[architecture-overview]]
 === Overview
 
-image:images/architecture/data_access_layers.svg[Data Access Layers]
+image::images/architecture/data_access_layers.svg[Data Access Layers,align="center"]
 
 Hibernate, as an ORM solution, effectively "sits between" the Java application data access layer and the Relational Database, as can be seen in the diagram above.
 The Java application makes use of the Hibernate APIs to load, store, query, etc. its domain data.
@@ -13,7 +13,7 @@ This will be a brief introduction; we will discuss these contracts in detail lat
 
 As a Jakarta Persistence provider, Hibernate implements the Java Persistence API specifications and the association between Jakarta Persistence interfaces and Hibernate specific implementations can be visualized in the following diagram:
 
-image:images/architecture/JPA_Hibernate.svg[image]
+image::images/architecture/JPA_Hibernate.svg[image,align="center"]
 
 SessionFactory (`org.hibernate.SessionFactory`):: A thread-safe (and immutable) representation of the mapping of the application domain model to a database.
 Acts as a factory for `org.hibernate.Session` instances. The `EntityManagerFactory` is the Jakarta Persistence equivalent of a `SessionFactory` and basically, those two converge into the same `SessionFactory` implementation.

documentation/src/main/asciidoc/userguide/chapters/batch/Batching.adoc

@@ -328,7 +328,7 @@ Dialect support through `org.hibernate.dialect.Dialect.getFallbackSqmMutationStr
 
 Considering we have the following entities:
 
-image:images/domain/bulkid/temp_table_class_diagram.png[Entity class diagram]
+image::images/domain/bulkid/temp_table_class_diagram.png[Entity class diagram,align="center"]
 
 The `Person` entity is the base class of this entity inheritance model, and is mapped as follows:
 

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

@@ -16,7 +16,7 @@ Table per class:: Each subclass has its own table containing both the subclass a
 
 In the following domain model class hierarchy, a `DebitAccount` and a `CreditAccount` share the same `Account` base class.
 
-image:images/domain/inheritance/inheritance_class_diagram.svg[Inheritance class diagram]
+image::images/domain/inheritance/inheritance_class_diagram.svg[Inheritance class diagram,align="center"]
 
 When using `MappedSuperclass`, the inheritance is visible in the domain model only, and each database table contains both the base class and the subclass properties.
 

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

@@ -40,7 +40,7 @@ the database column that it maps to, we need to implicitly determine that column
 examples of the role of the `org.hibernate.boot.model.naming.ImplicitNamingStrategy` contract to
 determine a logical name when the mapping did not provide an explicit name.
 
-image:images/domain/naming/implicit_naming_strategy_diagram.svg[Implicit Naming Strategy Diagram]
+image::images/domain/naming/implicit_naming_strategy_diagram.svg[Implicit Naming Strategy Diagram,align="center"]
 
 Hibernate defines multiple ImplicitNamingStrategy implementations out-of-the-box.  Applications
 are also free to plug in custom implementations.

documentation/src/main/asciidoc/userguide/chapters/multitenancy/MultiTenancy.adoc

@@ -27,7 +27,7 @@ Such topics are beyond the scope of this documentation.
 [[multitenacy-separate-database]]
 ==== Separate database
 
-image:images/multitenancy/multitenacy_database.png[]
+image::images/multitenancy/multitenacy_database.png[align="center"]
 
 Each tenant's data is kept in a physically separate database instance.
 JDBC Connections would point specifically to each database so any pooling would be per-tenant.
@@ -36,7 +36,7 @@ A general application approach, here, would be to define a JDBC Connection pool
 [[multitenacy-separate-schema]]
 ==== Separate schema
 
-image:images/multitenancy/multitenacy_schema.png[]
+image::images/multitenancy/multitenacy_schema.png[align="center"]
 
 Each tenant's data is kept in a distinct database schema on a single database instance.
 There are two different ways to define JDBC Connections here:
@@ -50,7 +50,7 @@ Using this approach, we would have a single JDBC Connection pool for use to serv
 [[multitenacy-discriminator]]
 ==== Partitioned (discriminator) data
 
-image:images/multitenancy/multitenacy_discriminator.png[]
+image::images/multitenancy/multitenacy_discriminator.png[align="center"]
 
 All data is kept in a single database schema.
 The data for each tenant is partitioned by the use of partition value or discriminator.