Skip to content
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

Document which channel adapter / gateway is Reactor friendly or not in the endpoints table #3773

Open
markusherbert opened this issue Apr 9, 2022 · 1 comment
Labels
status: waiting-for-triage The issue need to be evaluated and its future decided type: enhancement

Comments

@markusherbert
Copy link

markusherbert commented Apr 9, 2022

Expected Behavior
I think we should document which endpoint in the endpoints table is Reactor friendly or not. I'd like there to be a check (like a V tag, different color, or another signal) that will help users to understand if this Inbound Adapter/ Outbound Adapter/ Inbound Gateway/ Outbound Gateway has a reactive option or not. In regards to async implementations, I'm not sure if this should be classified as reactive, get mentioned in another category, or don't get mentioned at all.

Current Behavior
It's really hard to understand for example if the MqttPahoMessageHandler can interact reactively or not. The same is relevant for most of the extensions. Resolving this issue can improve Reactive Spring Integration users' life very much.

Context
I really suffer from understanding which channel adapter/ gateway has a reactive behavior or not, except in cases like ReactiveMongoDbStoringMessageHandler etc. I've also seen the need for this in #3771.

@markusherbert markusherbert added status: waiting-for-triage The issue need to be evaluated and its future decided type: enhancement labels Apr 9, 2022
@artembilan
Copy link
Member

I'm not sure that this one has really some value.
We have that table with links to target channel adapters. You follow them and determine from their specif chapter if they are reactive or not.
The reactive is not a top-level feature of Spring Integration. It is more implementation details of the specific component.
Therefore such a table must not be overcomplicated with an extra info which could be inferred from the target docs.
I doubt "reactive" is a first question people are asking looking into Spring Integration reference manual.

I'm not closing this one since we may gather other arguments yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: waiting-for-triage The issue need to be evaluated and its future decided type: enhancement
Projects
None yet
Development

No branches or pull requests

2 participants