Reputation: 136
After visualizing my flow (using this great project, btw.), I've noticed that there are bridge
components (together with DirectChannel
s) inserted right after my router
:
My DSL configuration:
.route(Message.class, messageTypeHeader(), mapping -> mapping
.id("filteringRouterEndpoint")
.resolutionRequired(false)
.defaultSubFlowMapping(rejectedByFiltersFlow)
.subFlowMapping(MessageType.TYPE_1, s -> s
.channel("type1MappingChannel")
.filter(type1MappingFilter)
.channel(ACCEPTED_BY_FILTERS_CHANNEL_NAME))
.subFlowMapping(MessageType.TYPE_2, s -> s
.channel("type2MappingChannel")
.filter(type2MappingFilter)
.channel(ACCEPTED_BY_FILTERS_CHANNEL_NAME))
.subFlowMapping(MessageType.TYPE_3, s -> s
.channel("type3MappingChannel")
.filter(type3MappingFilter)
.channel(ACCEPTED_BY_FILTERS_CHANNEL_NAME)))
(some names are different than on the flow, just to simplify)
I've noticed, that if I don't specify the channels explicitly on the beginning of the mapping subflows (i.e. typeXMappingChannel
s), then the bridges aren't created:
but I want to specify channels by myself, just to know their exact name, or to have other than DirectChannel
implementation for example.
What is the reason for that? Or maybe I made something wrong in my configuration?
Upvotes: 2
Views: 82
Reputation: 174719
It's an artifact of how the flow is constructed.
When we call .subflowMapping()
we start to build a flow that begins with a channel. Since we haven't encountered the first element of the flow yet .channel()
in your case, we build a default input channel.
Then, when we encounter the .channel()
we see the previous component is a channel, so we bridge it.
We could possibly optimize it out for this specific case; I'll take a look, but it will likely be a 5.2 change if we do it.
Upvotes: 1