Skip to content

Add Multi-input Bridge #2708

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

Closed
garyrussell opened this issue Jan 22, 2019 · 10 comments · Fixed by #3784
Closed

Add Multi-input Bridge #2708

garyrussell opened this issue Jan 22, 2019 · 10 comments · Fixed by #3784

Comments

@garyrussell
Copy link
Contributor

garyrussell commented Jan 22, 2019

Perhaps

@BridgeFrom({ channels = "foo", "bar", "*.baz.*" })
@Bean
public MessageChannel out() {
    ...
}

and create multiple bridges.

See spring-cloud/spring-cloud-stream#1582 for one use case.

Also consider adding @Repeatable(BridgesFrom.class) to @BridgeFrom

@garyrussell garyrussell added this to the 5.2.M1 milestone Jan 22, 2019
@garyrussell
Copy link
Contributor Author

Pattern(s) might be tricky unless we move annotation processing to later in the context lifecycle; we can't getBeansOfType in a BPP.

@artembilan
Copy link
Member

Sounds like we need to think about MultiInputConsumerEndpoint or CompositeIntegrationConsumer to support several input channels including patterns.

In the past, when I developed applications using Spring Integration, I also thought why there is no fan-in support when we would like to dump several channels to a single one...
Doesn't sound like should be as a general feature, but at least the bridge capabilities...

@artembilan
Copy link
Member

Seems for me we end up with the replyChannel header population in the end of each flow. I mean the @BridgeTo with upstream HeaderEnricher does the required trick.

Although i don't mind to go ahead with proposed feature to avoid even that boilerplate code. 😄

garyrussell added a commit to garyrussell/spring-integration that referenced this issue Jan 23, 2019
@garyrussell
Copy link
Contributor Author

MultiInputChannel consumer PoC here... garyrussell@e10722d

@artembilan
Copy link
Member

Yeah... The problem is that you don't support PollableChannel and ReactiveStreamsSubscribableChannel over there.
That's why I thought about CompositeIntegrationConsumer instead. Where every channel will get its own endpoint.

But we can continue to play.
Thank you for cracking this one!

@garyrussell
Copy link
Contributor Author

I am trying to avoid too much work in the annotation BPP - if we want to support patterns then we can't resolve channels early.

But, yes, some kind of wrapper around the existing consumers should work.

@artembilan
Copy link
Member

While it is still hot in mind mind I would like to share it.
Another way to achieve a request is like @Repeatable hint:

@BridgeFrom("channel1")
@BridgeFrom(value = "channel2", poller = @Poller)

Similar trick we should apply for all the Messaging annotations.
I even believe that we don't need to modify anything in the MessagingAnnotationPostProcessor.

Might be as a separate issue though, since this one is more about pattern matching support and composite endpoint.

@garyrussell
Copy link
Contributor Author

garyrussell commented Feb 7, 2019

Yes; I included that in the original description 😄

Also consider adding @Repeatable(BridgesFrom.class) to @BridgeFrom

But, yes, it could apply to all.

@artembilan
Copy link
Member

The same concept must be applied for the @StreamListener in the Spring Cloud Stream: https://stackoverflow.com/questions/54573861/spring-cloud-stream-how-to-specify-single-message-handler-for-a-set-of-bindings

@garyrussell garyrussell modified the milestones: 5.2.M1, 5.2.x Apr 3, 2019
@garyrussell garyrussell modified the milestones: 5.3.x, Backlog Mar 31, 2020
@artembilan
Copy link
Member

@artembilan artembilan self-assigned this Apr 18, 2022
@artembilan artembilan modified the milestones: Backlog, 6.0 M3 Apr 18, 2022
artembilan added a commit to artembilan/spring-integration that referenced this issue Apr 18, 2022
Fixes spring-projects#2708

There are some requests to use the same service method for different input channels

* Make all the messaging annotations as `@Repeatable` with their
respective container annotations
* Modify `MessagingAnnotationPostProcessor` logic to deal with the mentioned repeatable
requirements
garyrussell pushed a commit that referenced this issue Apr 19, 2022
Fixes #2708

There are some requests to use the same service method for different input channels

* Make all the messaging annotations as `@Repeatable` with their
respective container annotations
* Modify `MessagingAnnotationPostProcessor` logic to deal with the mentioned repeatable
requirements
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants