Skip to content

Conversation

artembilan
Copy link
Member

  • Deprecate an AbstractMessageSourceAdvice in favor of
    default method in the MessageSourceMutator
  • Move a applyReceiveOnlyAdviceChain() logic into the AbstractPollingEndpoint:
    now both PollingConsumer and SourcePollingChannelAdapter can use
    ReceiveMessageAdvice
  • Introduce a SimpleActiveIdleReceiveMessageAdvice based already
    on the ReceiveMessageAdvice and deprecate a SimpleActiveIdleMessageSourceAdvice
    which is fully replaceable with newly introduced SimpleActiveIdleReceiveMessageAdvice
  • Add @SuppressWarnings("deprecation") for those out-of-the-box ReceiveMessageAdvice
    implementation which still use an AbstractMessageSourceAdvice for
    backward compatibility
  • Document a new feature and give the MessageSourceMutator a new meaning

* Deprecate an `AbstractMessageSourceAdvice` in favor of
`default` method in the `MessageSourceMutator`
* Move a `applyReceiveOnlyAdviceChain()` logic into the `AbstractPollingEndpoint`:
now both `PollingConsumer` and `SourcePollingChannelAdapter` can use
`ReceiveMessageAdvice`
* Introduce a `SimpleActiveIdleReceiveMessageAdvice` based already
on the `ReceiveMessageAdvice` and deprecate a `SimpleActiveIdleMessageSourceAdvice`
which is fully replaceable with newly introduced `SimpleActiveIdleReceiveMessageAdvice`
* Add `@SuppressWarnings("deprecation")` for those out-of-the-box `ReceiveMessageAdvice`
implementation which still use an `AbstractMessageSourceAdvice` for
backward compatibility
* Document a new feature and give the `MessageSourceMutator` a new meaning
@artembilan artembilan requested a review from garyrussell April 28, 2020 14:19

@Override
@Nullable
public Message<?> afterReceive(@Nullable Message<?> result, Object source) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't something like Advisable<T> be better than Object?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, in most cases it is really about both MessageSource and PollableChannel, so even with generic argument it still going to be an Object 😄

I thought about a Supplier for both those interfaces, but this is not what we are going to use with the receive(timeout).
Therefore I'm OK to stick with an Object for a source argument.

@artembilan artembilan requested a review from garyrussell April 28, 2020 16:34
@garyrussell garyrussell merged commit 2d9a5f6 into spring-projects:master Apr 28, 2020
akuma8 pushed a commit to akuma8/spring-integration that referenced this pull request May 9, 2020
* Introduce a `ReceiveMessageAdvice`

* Deprecate an `AbstractMessageSourceAdvice` in favor of
`default` method in the `MessageSourceMutator`
* Move a `applyReceiveOnlyAdviceChain()` logic into the `AbstractPollingEndpoint`:
now both `PollingConsumer` and `SourcePollingChannelAdapter` can use
`ReceiveMessageAdvice`
* Introduce a `SimpleActiveIdleReceiveMessageAdvice` based already
on the `ReceiveMessageAdvice` and deprecate a `SimpleActiveIdleMessageSourceAdvice`
which is fully replaceable with newly introduced `SimpleActiveIdleReceiveMessageAdvice`
* Add `@SuppressWarnings("deprecation")` for those out-of-the-box `ReceiveMessageAdvice`
implementation which still use an `AbstractMessageSourceAdvice` for
backward compatibility
* Document a new feature and give the `MessageSourceMutator` a new meaning

* * Fix language in the `polling-consumer.adoc`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants