Какова цель автоматического добавления компонента моста после маршрутизатора?
После визуализации моего потока (кстати, с использованием отличного проекта это) я заметил, что компоненты bridge (вместе с DirectChannels) вставлены сразу после моего router:
Моя конфигурация DSL:
.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)))
(некоторые названия отличаются от на потоке, просто для упрощения)
Я заметил, что если я не укажу каналы явно в начале подпотоков отображения (т.е. typeXMappingChannels), то мосты не будут созданы:
но я хочу указать каналы сам, просто чтобы знать их точное название, или чтобы иметь другую реализацию, например, DirectChannel.
В чем причина этого? Или может я что-то не так сделал в настройках?
Ответы 1
Это артефакт того, как устроен поток.
Когда мы вызываем .subflowMapping(), мы начинаем строить поток, который начинается с канала. Поскольку мы еще не встретили первый элемент потока .channel() в вашем случае, мы строим входной канал по умолчанию.
Затем, когда мы сталкиваемся с .channel(), мы видим, что предыдущий компонент является каналом, поэтому мы соединяем его.
Возможно, мы могли бы оптимизировать его для этого конкретного случая; Я посмотрю, но, скорее всего, это будет изменение 5.2, если мы это сделаем.
Я думаю, нам нужно рассматривать это как Работает как задумано. Теперь у вас есть channel() в «начале» подпотока, но в конце концов вы решите добавить что-то еще раньше. По сути, это определенно не начало потока. Это нечто среднее. И именно поэтому мы ввели такую функцию, как внедрение компонентов потока в качестве подпотоков. Я бы сказал, что нам просто нужно задокументировать это поведение и показать в документах, как побороть, если что.
Спасибо ребята за разъяснение! Да, возможно, некоторые заметки в документах будут полезны :)
Обходной путь для вас — дефилировать все эти лямбды подпотока как отдельные
@Bean IntegrationFlow. Тогда ихinputChannelбудет правильно разрешен, и никаких дополнительных каналов и мостов создаваться не будет.