Introduce HeaderFilterSpec to streamline DSL API #8636
Conversation
The concern has been driven by the discussion from: spring-projects#8625 The point is that Java method arguments are not so descriptive when we read the code. Therefore, it is better to design DSL the way it would be cleaner from reading perspective. Plus less choice of methods to chain would give a better end-user experience from coding. * Add a `HeaderFilterSpec` which can accept `headersToRemove` and `patternMatch` as individual options instead of top-level deprecated `headerFilter(headersToRemove, patternMatch)` `IntegrationFlow` method. This way Kotlin and Groovy DSLs get a gain from their "inner section" style. * Such a `Consumer<HeaderFilterSpec>` way to configure an endpoint is similar to already existing `aggregate(Consumer<AggregatorSpec>)`, `resequence(Consumer<ResequencerSpec>)` etc. In other words those components which has a dedicated `ConsumerEndpointSpec` extension are OK from an idiomatic DSL style perspective * Expose a `HeaderFilter.setHeadersToRemove()` to make it working smoothly with this new DSL requirements * Apply a new `headerFilter()` style into Kotlin and Groovy DSLs This is just an initial work to surface an idea. If it is OK, I'll slow continue with others to realign and simplify the paradox of choice.
| import org.springframework.integration.router.MethodInvokingRouter | ||
| import org.springframework.integration.router.RecipientListRouter | ||
| import org.springframework.integration.handler.* | ||
| import org.springframework.integration.router.* |
There was a problem hiding this comment.
??
I guess checkstyle doesn't check Kotlin files.
There was a problem hiding this comment.
No, it does not https://checkstyle.org/index.html.
But I'll fix my IDE to not squash imports into asterisk.
Thanks
Yes, I want this merged. FYI: The failed test with Debezium batch mode is not related to the PR: I let @tzolov know that we have some race condition over there with batching or so. |
The concern has been driven by the discussion from: #8625 The point is that Java method arguments are not so descriptive when we read the code. Therefore, it is better to design DSL the way it would be cleaner from reading perspective. Plus less choice of methods to chain would give a better end-user experience from coding.
HeaderFilterSpecwhich can acceptheadersToRemoveandpatternMatchas individual options instead of top-level deprecatedheaderFilter(headersToRemove, patternMatch)IntegrationFlowmethod. This way Kotlin and Groovy DSLs get a gain from their "inner section" style.Consumer<HeaderFilterSpec>way to configure an endpoint is similar to already existingaggregate(Consumer<AggregatorSpec>),resequence(Consumer<ResequencerSpec>)etc. In other words those components which has a dedicatedConsumerEndpointSpecextension are OK from an idiomatic DSL style perspectiveHeaderFilter.setHeadersToRemove()to make it working smoothly with this new DSL requirementsheaderFilter()style into Kotlin and Groovy DSLsThis is just an initial work to surface an idea.
If it is OK, I'll slow continue with others to realign and simplify the paradox of choice.