Skip to content

Commit

Permalink
Add RabbitTemplate.getBeforePublishPostProcessors()
Browse files Browse the repository at this point in the history
The `RabbitTemplate` class currently provides a `addBeforePublishPostProcessors` method to configure `MessagePostProcessor` instances that can modify messages before they are sent. However, there is no corresponding `getBeforePublishPostProcessors` method to retrieve the currently configured processors. This PR introduces the `getBeforePublishPostProcessors` method, enhancing the flexibility and configurability of `RabbitTemplate`.

#### Justification:

1. **Increased Flexibility**:
   - While `addBeforePublishPostProcessors` allows users to configure message processors, there is currently no way to retrieve or modify the existing `MessagePostProcessor` list. Adding `getBeforePublishPostProcessors` gives users the ability to access and modify these processors dynamically, allowing for greater flexibility in scenarios where message processing needs to be altered based on context.

2. **Support for Multiple `RabbitTemplate` Instances**:
   - In more complex applications, it's common to create multiple `RabbitTemplate` instances to handle different business logic. For instance, the `ConfirmCallback` mechanism is globally applied, but by manually creating different `RabbitTemplate` instances, users can configure distinct callbacks for each instance. Introducing the `getBeforePublishPostProcessors` method will allow users to retrieve and reuse message processors between different `RabbitTemplate` instances, enhancing flexibility when handling different message routing and confirmation scenarios.

3. **Improved Consistency**:
   - Spring generally follows a "getter-setter" pattern for its components, and many classes offer both methods for configuring and retrieving values. By providing `getBeforePublishPostProcessors`, the API will become more consistent, following Spring’s design principles and making it easier for developers to interact with the `RabbitTemplate` class.

4. **Better Support for Advanced Use Cases**:
   - In advanced scenarios where users need to dynamically add or remove message processors based on business needs, the ability to retrieve the current processors simplifies the code. Without this getter method, developers need to manually track and manage `MessagePostProcessor` lists, which adds unnecessary complexity and can lead to duplication of logic.

5. **Enhanced Developer Experience**:
   - Having the ability to get the current `MessagePostProcessor` list helps developers debug and analyze the message pipeline more easily. This makes it simpler to understand how messages are being transformed before being sent, improving both the developer experience and troubleshooting process.
  • Loading branch information
leshalv authored Oct 8, 2024
1 parent 7f714b0 commit 1c429b8
Showing 1 changed file with 12 additions and 0 deletions.
Original file line number Diff line number Diff line change
Expand Up @@ -633,6 +633,18 @@ public void setBeanFactory(BeanFactory beanFactory) throws BeansException {
this.evaluationContext.addPropertyAccessor(new MapAccessor());
}

/**
* Return configured before post {@link MessagePostProcessor}s or {@code null}.
* @return configured before post {@link MessagePostProcessor}s or {@code null}.
* @since 3.2
*/
@Nullable
public Collection<MessagePostProcessor> getBeforePublishPostProcessors() {
return this.beforePublishPostProcessors != null
? Collections.unmodifiableCollection(this.beforePublishPostProcessors)
: null;
}

/**
* Set {@link MessagePostProcessor}s that will be invoked immediately before invoking
* {@code Channel#basicPublish()}, after all other processing, except creating the
Expand Down

0 comments on commit 1c429b8

Please sign in to comment.