Refer to message "receipt" instead of "reception"

This commit is contained in:
Sam Brannen
2024-11-19 13:17:42 +01:00
parent 874f056984
commit dd92eac3ad
11 changed files with 32 additions and 30 deletions

View File

@@ -1,5 +1,5 @@
/*
* Copyright 2002-2023 the original author or authors.
* Copyright 2002-2024 the original author or authors.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@@ -102,7 +102,7 @@ import org.springframework.util.ErrorHandler;
* (i.e. after your business logic executed but before the JMS part got committed),
* so duplicate message detection is just there to cover a corner case.
* <li>Or wrap your <i>entire processing with an XA transaction</i>, covering the
* reception of the JMS message as well as the execution of the business logic in
* receipt of the JMS message as well as the execution of the business logic in
* your message listener (including database operations etc). This is only
* supported by {@link DefaultMessageListenerContainer}, through specifying
* an external "transactionManager" (typically a

View File

@@ -45,7 +45,7 @@ import org.springframework.util.Assert;
*
* <p>This listener container variant is built for repeated polling attempts,
* each invoking the {@link #receiveAndExecute} method. The MessageConsumer used
* may be reobtained fo reach attempt or cached in between attempts; this is up
* may be reobtained for each attempt or cached in between attempts; this is up
* to the concrete implementation. The receive timeout for each attempt can be
* configured through the {@link #setReceiveTimeout "receiveTimeout"} property.
*
@@ -56,7 +56,7 @@ import org.springframework.util.Assert;
* full control over the listening process, allowing for custom scaling and throttling
* and of concurrent message processing (which is up to concrete subclasses).
*
* <p>Message reception and listener execution can automatically be wrapped
* <p>Message receipt and listener execution can automatically be wrapped
* in transactions through passing a Spring
* {@link org.springframework.transaction.PlatformTransactionManager} into the
* {@link #setTransactionManager "transactionManager"} property. This will usually
@@ -105,7 +105,7 @@ public abstract class AbstractPollingMessageListenerContainer extends AbstractMe
/**
* Specify the Spring {@link org.springframework.transaction.PlatformTransactionManager}
* to use for transactional wrapping of message reception plus listener execution.
* to use for transactional wrapping of message receipt plus listener execution.
* <p>Default is none, not performing any transactional wrapping.
* If specified, this will usually be a Spring
* {@link org.springframework.transaction.jta.JtaTransactionManager} or one
@@ -131,7 +131,7 @@ public abstract class AbstractPollingMessageListenerContainer extends AbstractMe
/**
* Return the Spring PlatformTransactionManager to use for transactional
* wrapping of message reception plus listener execution.
* wrapping of message receipt plus listener execution.
*/
@Nullable
protected final PlatformTransactionManager getTransactionManager() {

View File

@@ -47,7 +47,7 @@ import org.springframework.util.backoff.FixedBackOff;
/**
* Message listener container variant that uses plain JMS client APIs, specifically
* a loop of {@code MessageConsumer.receive()} calls that also allow for
* transactional reception of messages (registering them with XA transactions).
* transactional receipt of messages (registering them with XA transactions).
* Designed to work in a native JMS environment as well as in a Jakarta EE environment,
* with only minimal differences in configuration.
*
@@ -70,7 +70,7 @@ import org.springframework.util.backoff.FixedBackOff;
* {@code MessageConsumer} (only refreshed in case of failure), using the JMS provider's
* resources as efficiently as possible.
*
* <p>Message reception and listener execution can automatically be wrapped
* <p>Message receipt and listener execution can automatically be wrapped
* in transactions by passing a Spring
* {@link org.springframework.transaction.PlatformTransactionManager} into the
* {@link #setTransactionManager "transactionManager"} property. This will usually
@@ -474,7 +474,7 @@ public class DefaultMessageListenerContainer extends AbstractPollingMessageListe
/**
* Specify the maximum number of messages to process in one task.
* More concretely, this limits the number of message reception attempts
* More concretely, this limits the number of message receipt attempts
* per task, which includes receive iterations that did not actually
* pick up a message until they hit their timeout (see the
* {@link #setReceiveTimeout "receiveTimeout"} property).
@@ -562,7 +562,7 @@ public class DefaultMessageListenerContainer extends AbstractPollingMessageListe
* The minimum number of consumers
* (see {@link #setConcurrentConsumers "concurrentConsumers"})
* will be kept around until shutdown in any case.
* <p>Within each task execution, a number of message reception attempts
* <p>Within each task execution, a number of message receipt attempts
* (according to the "maxMessagesPerTask" setting) will each wait for an incoming
* message (according to the "receiveTimeout" setting). If all of those receive
* attempts in a given task return without a message, the task is considered

View File

@@ -56,7 +56,7 @@ import org.springframework.util.Assert;
*
* <p>For a different style of MessageListener handling, through looped
* {@code MessageConsumer.receive()} calls that also allow for
* transactional reception of messages (registering them with XA transactions),
* transactional receipt of messages (registering them with XA transactions),
* see {@link DefaultMessageListenerContainer}.
*
* @author Juergen Hoeller

View File

@@ -1,5 +1,5 @@
/*
* Copyright 2002-2017 the original author or authors.
* Copyright 2002-2024 the original author or authors.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@@ -89,7 +89,7 @@ public interface JmsHeaders {
/**
* Specify if the message was resent. This occurs when a message
* consumer fails to acknowledge the message reception.
* consumer fails to acknowledge receipt of the message.
* <p>Read-only value.
* @see jakarta.jms.Message#getJMSRedelivered()
*/