Refer to message "receipt" instead of "reception"

framework-docs/modules/ROOT/pages/integration/jms.adoc

@@ -6,7 +6,7 @@ the same way as Spring's integration does for the JDBC API.
 
 JMS can be roughly divided into two areas of functionality, namely the production and
 consumption of messages. The `JmsTemplate` class is used for message production and
-synchronous message reception. For asynchronous reception similar to Jakarta EE's
+synchronous message receipt. For asynchronous receipt similar to Jakarta EE's
 message-driven bean style, Spring provides a number of message-listener containers that
 you can use to create Message-Driven POJOs (MDPs). Spring also provides a declarative way
 to create message listeners.

framework-docs/modules/ROOT/pages/integration/jms/receiving.adoc

@@ -5,7 +5,7 @@ This describes how to receive messages with JMS in Spring.
 
 
 [[jms-receiving-sync]]
-== Synchronous Reception
+== Synchronous Receipt
 
 While JMS is typically associated with asynchronous processing, you can
 consume messages synchronously. The overloaded `receive(..)` methods provide this
@@ -16,7 +16,7 @@ the receiver should wait before giving up waiting for a message.
 
 
 [[jms-receiving-async]]
-== Asynchronous reception: Message-Driven POJOs
+== Asynchronous Receipt: Message-Driven POJOs
 
 NOTE: Spring also supports annotated-listener endpoints through the use of the `@JmsListener`
 annotation and provides open infrastructure to register endpoints programmatically.
@@ -154,7 +154,7 @@ listener container.
 
 You can activate local resource transactions through the `sessionTransacted` flag
 on the listener container definition. Each message listener invocation then operates
-within an active JMS transaction, with message reception rolled back in case of listener
+within an active JMS transaction, with message receipt rolled back in case of listener
 execution failure. Sending a response message (through `SessionAwareMessageListener`) is
 part of the same local transaction, but any other resource operations (such as
 database access) operate independently. This usually requires duplicate message
@@ -173,7 +173,7 @@ To configure a message listener container for XA transaction participation, you
 to configure a `JtaTransactionManager` (which, by default, delegates to the Jakarta EE
 server's transaction subsystem). Note that the underlying JMS `ConnectionFactory` needs to
 be XA-capable and properly registered with your JTA transaction coordinator. (Check your
-Jakarta EE server's configuration of JNDI resources.) This lets message reception as well
+Jakarta EE server's configuration of JNDI resources.) This lets message receipt as well
 as (for example) database access be part of the same transaction (with unified commit
 semantics, at the expense of XA transaction log overhead).
 

framework-docs/modules/ROOT/pages/integration/jms/using.adoc

@@ -167,13 +167,15 @@ operations that do not refer to a specific destination.
 
 One of the most common uses of JMS messages in the EJB world is to drive message-driven
 beans (MDBs). Spring offers a solution to create message-driven POJOs (MDPs) in a way
-that does not tie a user to an EJB container. (See xref:integration/jms/receiving.adoc#jms-receiving-async[Asynchronous reception: Message-Driven POJOs] for detailed
-coverage of Spring's MDP support.) Since Spring Framework 4.1, endpoint methods can be
-annotated with `@JmsListener` -- see xref:integration/jms/annotated.adoc[Annotation-driven Listener Endpoints] for more details.
+that does not tie a user to an EJB container. (See
+xref:integration/jms/receiving.adoc#jms-receiving-async[Asynchronous Receipt: Message-Driven POJOs]
+for detailed coverage of Spring's MDP support.) Endpoint methods can be annotated with
+`@JmsListener` -- see xref:integration/jms/annotated.adoc[Annotation-driven Listener Endpoints]
+for more details.
 
 A message listener container is used to receive messages from a JMS message queue and
 drive the `MessageListener` that is injected into it. The listener container is
-responsible for all threading of message reception and dispatches into the listener for
+responsible for all threading of message receipt and dispatches into the listener for
 processing. A message listener container is the intermediary between an MDP and a
 messaging provider and takes care of registering to receive messages, participating in
 transactions, resource acquisition and release, exception conversion, and so on. This
@@ -227,7 +229,7 @@ the JMS provider, advanced functionality (such as participation in externally ma
 transactions), and compatibility with Jakarta EE environments.
 
 You can customize the cache level of the container. Note that, when no caching is enabled,
-a new connection and a new session is created for each message reception. Combining this
+a new connection and a new session is created for each message receipt. Combining this
 with a non-durable subscription with high loads may lead to message loss. Make sure to
 use a proper cache level in such a case.
 
@@ -246,7 +248,7 @@ in the form of a business entity existence check or a protocol table check.
 Any such arrangements are significantly more efficient than the alternative:
 wrapping your entire processing with an XA transaction (through configuring your
 `DefaultMessageListenerContainer` with an `JtaTransactionManager`) to cover the
-reception of the JMS message as well as the execution of the business logic in your
+receipt of the JMS message as well as the execution of the business logic in your
 message listener (including database operations, etc.).
 
 IMPORTANT: The default `AUTO_ACKNOWLEDGE` mode does not provide proper reliability guarantees.

framework-docs/modules/ROOT/pages/integration/observability.adoc

@@ -126,7 +126,7 @@ This instrumentation will create 2 types of observations:
 * `"jms.message.publish"` when a JMS message is sent to the broker, typically with `JmsTemplate`.
 * `"jms.message.process"` when a JMS message is processed by the application, typically with a `MessageListener` or a `@JmsListener` annotated method.
 
-NOTE: Currently there is no instrumentation for `"jms.message.receive"` observations as there is little value in measuring the time spent waiting for the reception of a message.
+NOTE: Currently there is no instrumentation for `"jms.message.receive"` observations as there is little value in measuring the time spent waiting for the receipt of a message.
 Such an integration would typically instrument `MessageConsumer#receive` method calls. But once those return, the processing time is not measured and the trace scope cannot be propagated to the application.
 
 By default, both observations share the same set of possible `KeyValues`: