Skip to content

Add DSL transform() variant overload for accepting a bean name #8626

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.

Sign up for GitHub

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

Jump to bottom
Closed
altruie opened this issue May 17, 2023 · 0 comments · Fixed by #8653
Closed

Add DSL transform() variant overload for accepting a bean name #8626

altruie opened this issue May 17, 2023 · 0 comments · Fixed by #8653
Labels
ideal-for-user-contribution An issue that would ideal for a user to get started with contributing. in: dsl type: enhancement
Milestone
6.2.0-M1

Comments

@altruie
Copy link

altruie commented May 17, 2023

As discussed on thread for Issue #8625, there is a utility to have IntegrationFlows methods that accept a bean name, as is the case for

split(String beanName, @Nullable String methodName)

The transform() method does not have such a bean-name overload. It can be useful to have this in order to avoid the boilerplate injection of the bean via construction or bean method.
@aljopainter aljopainter mentioned this issue May 17, 2023
Closed
@artembilan artembilan added this to the 6.2.0-M1 milestone May 17, 2023
@artembilan artembilan added type: enhancement in: dsl ideal-for-user-contribution An issue that would ideal for a user to get started with contributing. labels May 17, 2023
artembilan added a commit to artembilan/spring-integration that referenced this issue Jun 16, 2023
@artembilan
spring-projectsGH-8626: Provide cleaner transform() DSL
b4a8585 
Fixes spring-projects#8626

* Add missed `transform(String beanName, @nullable String methodName)` API
* Introduce a `TransformerSpec` to expose a strict API to configure
transformer variants.
* Introduce `transformWith(Consumer<TransformerSpec>)` as a single point
of all possible transformer and its endpoint options
* Deprecate those `IntegrationFlowDefinition.transform()` variants
which are harder to configure as several lambda arguments

This change will make Kotlin & Groovy DSL more readable and straightforward
@artembilan artembilan mentioned this issue Jun 16, 2023
Merged
artembilan added a commit to artembilan/spring-integration that referenced this issue Jun 20, 2023
@artembilan
spring-projectsGH-8626: Provide cleaner transform() DSL
68399dc 
Fixes spring-projects#8626

* Add missed `transform(String beanName, @nullable String methodName)` API
* Introduce a `TransformerSpec` to expose a strict API to configure
transformer variants.
* Introduce `transformWith(Consumer<TransformerSpec>)` as a single point
of all possible transformer and its endpoint options
* Deprecate those `IntegrationFlowDefinition.transform()` variants
which are harder to configure as several lambda arguments

This change will make Kotlin & Groovy DSL more readable and straightforward
artembilan added a commit to artembilan/spring-integration that referenced this issue Jun 23, 2023
@artembilan
spring-projectsGH-8626: Provide cleaner transform() DSL
19e350c 
Fixes spring-projects#8626

* Add missed `transform(String beanName, @nullable String methodName)` API
* Introduce a `TransformerSpec` to expose a strict API to configure
transformer variants.
* Introduce `transformWith(Consumer<TransformerSpec>)` as a single point
of all possible transformer and its endpoint options
* Deprecate those `IntegrationFlowDefinition.transform()` variants
which are harder to configure as several lambda arguments

This change will make Kotlin & Groovy DSL more readable and straightforward
garyrussell pushed a commit that referenced this issue Jun 26, 2023
@artembilan
GH-8626: Provide cleaner transform() DSL (#8653)
070c1c6 
* GH-8626: Provide cleaner `transform()` DSL

Fixes #8626

* Add missed `transform(String beanName, @nullable String methodName)` API
* Introduce a `TransformerSpec` to expose a strict API to configure
transformer variants.
* Introduce `transformWith(Consumer<TransformerSpec>)` as a single point
of all possible transformer and its endpoint options
* Deprecate those `IntegrationFlowDefinition.transform()` variants
which are harder to configure as several lambda arguments

This change will make Kotlin & Groovy DSL more readable and straightforward

* * Use new `transformWith()` in tests where a deprecated API still used
* Add JavaDocs to `TransformerSpec`
* Fix generic types for `BaseIntegrationFlowDefinition.transformWith()` -
they make sense exactly on the `TransformerSpec.transformer()` only
* Apply `transformWith()` for Groovy DSL
* Introduce a new `ClassUtils.isLambda(Object candidate)`
and add a check for Groovy `Closure`
* Fix `GroovyIntegrationFlowDefinition.createConfigurerIfAny()` to propagate a `Consumer` argument
down to the `Closure`

* * Rename `TransformerSpec -> TransformerEndpointSpec` for better context
meaning of the class
* Introduce `KotlinTransformerEndpointSpec` as an extension of the `TransformerEndpointSpec`
to have an `inline fun <reified P> transformer(crossinline function: (P) -> Any)`
for Kotlin style
* Add `KotlinIntegrationFlowDefinition.transformWith(KotlinTransformerEndpointSpec)`
* Deprecate Kotlin methods which are covered by the mentioned `transformWith()`
* Fix tests to use new API
* Mentioned the change in the doc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
ideal-for-user-contribution An issue that would ideal for a user to get started with contributing. in: dsl type: enhancement
Projects
None yet
Milestone
6.2.0-M1
Development

Successfully merging a pull request may close this issue.

GH-8626: Provide cleaner transform() DSL artembilan/spring-integration
2 participants
@artembilan @altruie