New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Otherwise LGTM; do you want this merged or will you add more work to this PR?
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
??
I guess checkstyle doesn't check Kotlin files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
HeaderFilterSpec
which can acceptheadersToRemove
andpatternMatch
as individual options instead of top-level deprecatedheaderFilter(headersToRemove, patternMatch)
IntegrationFlow
method. 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 dedicatedConsumerEndpointSpec
extension 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.