more work on correct use of monospace font

spec/src/main/asciidoc/ch03-entity-operations.adoc

@@ -183,7 +183,7 @@ and persistent by invoking the `persist` method on it or by cascading
 the persist operation.
 
 The semantics of the persist operation,
-applied to an entity `X` are as follows:
+applied to an entity X are as follows:
 
 * If X is a new entity, it becomes managed. The
 entity X will be entered into the database at or before transaction
@@ -268,7 +268,7 @@ owning side of the relationship. It is the developer's responsibility to
 keep the in-memory references held on the owning side and those held on
 the inverse side consistent with each other when they change. In the
 case of unidirectional one-to-one and one-to-many relationships, it is
-the developer's responsibility to insure that the semantics of the
+the developer's responsibility to ensure that the semantics of the
 relationships are adhered to.footnote:[This might be an
 issue if unique constraints (such as those described for the default
 mappings in <<a640>> and <<a764>>) were not applied in the
@@ -297,7 +297,7 @@ active or if the persistence context has not been joined to the current
 transaction, the persistence provider must not flush to the database.
 
 The semantics of the flush operation, applied
-to an entity `X` are as follows:
+to an entity X are as follows:
 
 * If X is a managed entity, it is synchronized
 to the database.
@@ -316,7 +316,7 @@ the ownership of the relationship. If X owns the relationship, any
 changes to the relationship are synchronized with the database;
 otherwise, if Y owns the relationships, the behavior is undefined.
 * If X is a removed entity, it is removed from
-the database. No cascade options are relevant.
+the database. No `cascade` options are relevant.
 
 ==== Refreshing an Entity Instance
 
@@ -369,7 +369,7 @@ entities is annotated with the `cascade=DETACH` or `cascade=ALL`
 annotation element value. Entities which previously referenced X will
 continue to reference X. Portable applications should not pass removed
 entities that have been detached from the persistence context to further
-EntityManager operations.
+`EntityManager` operations.
 
 ==== Detached Entities [[a1982]]
 
@@ -382,7 +382,7 @@ or otherwise passing an entity by value—e.g., to a separate application
 tier, through a remote interface, etc.
 
 Detached entity instances continue to live
-outside of the persistence context in which they were persisted or
+outside the persistence context in which they were persisted or
 retrieved. Their state is no longer guaranteed to be synchronized with
 the database state.
 
@@ -556,7 +556,7 @@ extends beyond that of a single transaction (extended persistence
 context). The enum `PersistenceContextType` is used to define the
 persistence context lifetime scope for container-managed entity
 managers. The persistence context lifetime scope is defined when the
-EntityManager instance is created (whether explicitly, or in conjunction
+`EntityManager` instance is created (whether explicitly, or in conjunction
 with injection or JNDI lookup). See <<a11791>>.
 
 [source,java]
@@ -570,22 +570,22 @@ of a transaction (i.e., it is of type
 `PersistenceContextType.TRANSACTION`).
 
 When an extended persistence context is used,
-the extended persistence context exists from the time the EntityManager
+the extended persistence context exists from the time the `EntityManager`
 instance is created until it is closed. This persistence context might
 span multiple transactions and non-transactional invocations of the
-EntityManager.
+`EntityManager`.
 
-An EntityManager with an extended persistence
+An `EntityManager` with an extended persistence
 context maintains its references to the entity objects after a
 transaction has committed. Those objects remain managed by the
-EntityManager, and they can be updated as managed objects between
+`EntityManager`, and they can be updated as managed objects between
 transactions.footnote:[Note that when a new
 transaction is begun, the managed objects in an extended persistence
 context are `not` reloaded from the database.] Navigation from a managed object in
 an extended persistence context results in one or more other managed
 objects regardless of whether a transaction is active.
 
-When an EntityManager with an extended
+When an `EntityManager` with an extended
 persistence context is used, the persist, remove, merge, and refresh
 operations can be called regardless of whether a transaction is active.
 The effects of these operations will be committed to the database when
@@ -1050,7 +1050,7 @@ use `LockModeType.PESSIMISTIC_WRITE` where
 When the lock cannot be obtained, and the
 database locking failure results in transaction-level rollback, the
 provider must throw the `PessimisticLockException` and ensure that the
-JTA transaction or EntityTransaction has been marked for rollback.
+JTA transaction or `EntityTransaction` has been marked for rollback.
 
 When the lock cannot be obtained, and the
 database locking failure results in only statement-level rollback, the
@@ -1065,7 +1065,7 @@ provider is not required to flush the entity to the database
 immediately.] If the lock conversion fails, and the
 database locking failure results in transaction-level rollback, the
 provider must throw the `PessimisticLockException` and ensure that the
-JTA transaction or EntityTransaction has been marked for rollback. When
+JTA transaction or `EntityTransaction` has been marked for rollback. When
 the lock conversion fails, and the database locking failure results in
 only statement-level rollback, the provider must throw the
 `LockTimeoutException` (and must not mark the transaction for
@@ -1374,7 +1374,7 @@ The following rules apply to lifecycle callback methods:
 
 The `PrePersist` and `PreRemove` callback
 methods are invoked for a given entity before the respective
-EntityManager persist and remove operations for that entity are
+`EntityManager` persist and remove operations for that entity are
 executed. For entities to which the merge operation has been applied and
 causes the creation of newly managed instances, the `PrePersist`
 callback methods will be invoked for the managed instance after the

spec/src/main/asciidoc/ch06-criteria-api.adoc

@@ -860,11 +860,11 @@ If a name is supplied when the
 `ParameterExpression` instance is created, the parameter may also be
 treated as a named parameter when the query is executed:
 
+[source,java]
+----
 CriteriaQuery<Customer> q =
 cb.createQuery(Customer.class);
 
-[source,java]
-----
 Root<Customer> c = q.from(Customer.class);
 ParameterExpression<Integer> param = cb.parameter(Integer.class, "stat");
 q.select(c).where(cb.equal(c.get(Customer_.status), param));

spec/src/main/asciidoc/ch07-entitymanagers-and-persistence-contexts.adoc

@@ -18,22 +18,22 @@ transaction. To facilitate such use of entity managers in Jakarta EE
 environments, when an entity manager is injected into a component or
 looked up directly in the JNDI naming context, its persistence context
 will automatically be propagated with the current JTA transaction, and
-the EntityManager references that are mapped to the same persistence
+the `EntityManager` references that are mapped to the same persistence
 unit will provide access to this same persistence context within the JTA
 transaction. This propagation of persistence contexts by the Jakarta EE
 container avoids the need for the application to pass references to
-EntityManager instances from one component to another. An entity manager
+`EntityManager` instances from one component to another. An entity manager
 for which the container manages the persistence context in this manner
 is termed a _container-managed entity manager_. A container-managed
 entity manager's lifecycle is managed by the Jakarta EE container.
 
 In less common use cases within Jakarta EE
 environments, applications may need to access a persistence context that
 is “stand-alone”—i.e. not propagated along with the JTA transaction
-across the EntityManager references for the given persistence unit.
+across the `EntityManager` references for the given persistence unit.
 Instead, each instance of creating an entity manager causes a new
 isolated persistence context to be created that is not accessible
-through other EntityManager references within the same transaction.
+through other `EntityManager` references within the same transaction.
 These use cases are supported through the `createEntityManager` methods
 of the `EntityManagerFactory` interface. An entity manager that is used
 by the application to create and destroy a persistence context in this
@@ -251,7 +251,7 @@ be used for vendor-specific information. The namespace
 === Controlling Transactions
 
 Depending on the transactional type of the
-entity manager, transactions involving EntityManager operations may be
+entity manager, transactions involving `EntityManager` operations may be
 controlled either through JTA or through use of the resource-local
 `EntityTransaction` API, which is mapped to a resource transaction over
 the resource that underlies the entities managed by the entity manager.
@@ -499,7 +499,7 @@ as `PersistenceContextType.TRANSACTION`.
 
 A new persistence context begins when the
 container-managed entity manager is invokedfootnote:[Specifically, when
-one of the methods of the EntityManager interface is invoked.] in
+one of the methods of the `EntityManager` interface is invoked.] in
 the scope of an active JTA transaction, and there is no current
 persistence context already associated with the JTA transaction. The
 persistence context is created and then associated with the JTA
@@ -510,7 +510,7 @@ to the transaction.
 
 The persistence context ends when the
 associated JTA transaction commits or rolls back, and all entities that
-were managed by the EntityManager become detached.footnote:[Note that this
+were managed by the `EntityManager` become detached.footnote:[Note that this
 applies to a transaction-scoped persistence context of type
 SynchronizationType.UNSYNCHRONIZED that has not been joined to the
 transaction as well.]
@@ -1015,7 +1015,7 @@ Note that the JTA transaction may rollback in a
 background thread (e.g., as a result of transaction timeout), in which
 case the container should arrange for the entity manager to be closed
 but the `EntityManager.close` method should not be concurrently invoked
-while the application is in an EntityManager invocation.
+while the application is in an `EntityManager` invocation.
 
 The container must throw the
 `TransactionRequiredException` if a transaction-scoped persistence
@@ -1094,7 +1094,7 @@ to the transaction. Note that the JTA transaction may rollback in a
 background thread (e.g., as a result of transaction timeout), in which
 case the provider should arrange for the managed entities to be detached
 from the persistence context but not concurrently while the application
-is in an EntityManager invocation.
+is in an `EntityManager` invocation.
 * When the provider throws an exception defined
 to cause transaction rollback, the provider must mark the transaction
 for rollback if the persistence context is of type

spec/src/main/asciidoc/ch09-container-provider-contracts.adoc

@@ -55,9 +55,9 @@ used must be the standard property name `jakarta.persistence.bean.manager`.
 
 The `EntityManagerFactory` instance obtained
 as a result will be used by the container to create container-managed
-entity managers. Only one EntityManagerFactory is permitted to be
+entity managers. Only one `EntityManagerFactory` is permitted to be
 created for each deployed persistence unit configuration. Any number of
-EntityManager instances may be created from a given factory.
+`EntityManager` instances may be created from a given factory.
 
 In a Jakarta EE environment, the classes of the
 persistence unit should not be loaded by the application class loader or

spec/src/main/asciidoc/ch10-metadata-annotations.adoc

@@ -48,7 +48,7 @@ public @interface EntityListeners {
 }
 ----
 
-The ExcludeSuperclassListeners annotation
+The `ExcludeSuperclassListeners` annotation
 specifies that the invocation of superclass listeners is to be excluded
 for the entity class (or mapped superclass) and its subclasses.
 
@@ -60,7 +60,7 @@ public @interface ExcludeSuperclassListeners {
 }
 ----
 
-The ExcludeDefaultListeners annotation
+The `ExcludeDefaultListeners` annotation
 specifies that the invocation of default listeners is to be excluded for
 the entity class (or mapped superclass) and its subclasses.
 
@@ -576,7 +576,7 @@ The `synchronizationType` element specifies
 whether the persistence context is always automatically synchronized
 with the current transaction or whether the persistence context must be
 explicitly joined to the current transaction by means of the
-EntityManager `joinTransaction` method.
+`joinTransaction` method of `EntityManager`.
 
 The optional `properties` element may be used
 to specify properties for the container or persistence provider.