Какова цель автоматического добавления компонента моста после маршрутизатора? - PullRequest
2 голосов
/ 09 апреля 2019

После визуализации моего потока (используя этот отличный проект, кстати), я заметил, что сразу после моего router вставлено bridge компонентов (вместе с DirectChannel s):

flow visualization

Моя конфигурация 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)))

(некоторые имена отличаются от потока, просто для упрощения)

Я заметил, что если я не указываю каналы явно в начале подпотоков отображения (т. Е. typeXMappingChannel s), то мосты не создаются: flow visualization 2

, но я хочу сам указать каналы, просто чтобы знать их точное название или иметь, например, реализацию, отличную от DirectChannel.

В чем причина?А может я что-то не так сделал в своей конфигурации?

1 Ответ

1 голос
/ 09 апреля 2019

Это артефакт того, как устроен поток.

Когда мы вызываем .subflowMapping(), мы начинаем строить поток, который начинается с канала. Поскольку в вашем случае мы еще не встретили первый элемент потока .channel(), мы строим входной канал по умолчанию.

Затем, когда мы сталкиваемся с .channel(), мы видим, что предыдущий компонент является каналом, поэтому мы соединяем его.

Мы могли бы оптимизировать его для этого конкретного случая; Я посмотрю, но если мы сделаем это, то, скорее всего, изменится на 5.2.

GH-2890

...