Skip to content

Conversation

@artembilan
Copy link
Member

  • Introduce a SplitterSpec which can accept possible splitter variants: expression, function, ref etc. This way we are going to have a complex endpoint configuration only with a single method argument.
  • Use SplitterSpec in a newly introduced splitWith()
  • Deprecate those split() methods which use SplitterEndpointSpec. This method are complex enough because of their several arguments
  • Refactor some common MessageHandler options initialization into the ConsumerEndpointSpec.doGet()
  • Disable failing now MethodInvokingMessageProcessorTests.testCollectionArgument(): or Jackson problem, or fresh SF
  • Groovy DSL will be fixed in the separate PR: https://stackoverflow.com/questions/76595843/groovy-selects-a-defaultgroovymethods-split-instead-of-mine-one

* Introduce a `SplitterSpec` which can accept possible
splitter variants: `expression`, `function`, `ref` etc.
This way we are going to have a complex endpoint configuration
only with a single method argument.
* Use `SplitterSpec` in a newly introduced `splitWith()`
* Deprecate those `split()` methods which use `SplitterEndpointSpec`.
This method are complex enough because of their several arguments
* Refactor some common `MessageHandler` options initialization
into the `ConsumerEndpointSpec.doGet()`
* Disable failing now `MethodInvokingMessageProcessorTests.testCollectionArgument()`:
or Jackson problem, or fresh SF
* Groovy DSL will be fixed in the separate PR:
https://stackoverflow.com/questions/76595843/groovy-selects-a-defaultgroovymethods-split-instead-of-mine-one
@garyrussell garyrussell merged commit 34f901f into spring-projects:main Jul 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants