Skip to content

Conversation

artembilan
Copy link
Member

Fixes: #8981

Sometime the simple boolean failover on the MessageChannel (default true) is not enough to be sure that we can dispatch to the next handler or not. Such a decision can be made using ErrorMessageExceptionTypeRouter, but that would require an overhaul for the whole integration flow

  • Introduce a simple Predicate<Exception> failoverStrategy into UnicastingDispatcher and all its MessageChannel implementation consumers to allow to make a decision about next failover according to a thrown exception from the current MessageHandler
  • Expose failoverStrategy on the DirectChannel, ExecutorChannel & PartitionedChannel, and add it into respective Java DSL specs
  • Fix involved tests to rely on the failoverStrategy property from now on
  • Document the new feature

@artembilan artembilan requested a review from sobychacko March 8, 2024 19:55
…ption

Fixes: spring-projects#8981

Sometime the simple `boolean failover` on the `MessageChannel` (default `true`)
is not enough to be sure that we can dispatch to the next handler or not.
Such a decision can be made using `ErrorMessageExceptionTypeRouter`, but that would
require an overhaul for the whole integration flow

* Introduce a simple `Predicate<Exception> failoverStrategy` into `UnicastingDispatcher`
and all its `MessageChannel` implementation consumers to allow to make a decision about next failover
according to a thrown exception from the current `MessageHandler`
* Expose `failoverStrategy` on the `DirectChannel`, `ExecutorChannel` & `PartitionedChannel`,
and add it into respective Java DSL specs
* Fix involved tests to rely on the `failoverStrategy` property from now on
* Document the new feature
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
@SpringJUnitConfig
public class DispatchingChannelParserTests {
Copy link
Contributor

Choose a reason for hiding this comment

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

One general comment: since you are modifying a test, why don't we clean this up as JUnit 5 style tests? i.e - keeping the test class and the test methods with default access?

Copy link
Member Author

Choose a reason for hiding this comment

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

This is not enforced style, so I leave it up personal preferences. Since this is an existing class, I wouldn’t bother removing those public words.
The new test is just a copy/paste artifact , so still no care 😅

}

@Test
public void failoverStrategyRejects() {
Copy link
Contributor

Choose a reason for hiding this comment

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

Junit 5 style tests?

@artembilan artembilan merged commit ffe3605 into spring-projects:main Mar 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

2 participants