Используя Spring-Camel, я построил маршрут, который использует тему JMS (с JMSReplyTo, как ожидается, будет установлен для каждого входного сообщения), разбивает сообщение на более мелкие куски, отправляет их в обработчик REST, затем объединяет ответы и должен выдать выходное сообщение в пункт назначения, указанный JMSReplyTo. К сожалению, верблюд неявно использует пункт назначения JMSReplyTo на одном из промежуточных этапов (производя неархивированный POJO).
У нас есть функциональное требование для адаптации JMSReplyTo для предоставления услуги обмена сообщениями запрос-ответ.
Я могу прочитать заголовок JMSReplyTo до окончания маршрута, и я явно преобразую его в CamelJmsDestinationName, который успешно переопределяет назначение для компонента JMS и выдает сообщение в теме вывода. Я не уверен, что это лучший подход, и проблема в том, что верблюд все еще использует JMSReplyTo самостоятельно.
Моя конфигурация RouteBuilder следующая:
from("jms:topic:T.INPUT")
.process(requestProcessor)
.unmarshal().json(JsonLibrary.Jackson, MyRequest.class)
.split(messageSplitter)
.process(restProcessor)
.aggregate(messagesAggregator)
.unmarshal().json(JsonLibrary.Jackson, BulkResponses.class)
.process(responseProcessor)
.to("jms:topic:recipientTopic");
T.INPUT - это имя входной темы, а receientTopic - просто заполнитель, который будет заменен на CamelJmsDestinationName.
Я не заинтересован в использовании CamelJmsDestinationName и своего рода смоделированного имени темы в конфигурации маршрута, поэтому я готов найти лучшее решение. Было бы замечательно, если бы верблюд автоматически использовал JMSReplyTo для создания выходного сообщения в теме вывода.
В настоящее время проблема заключается в том, что верблюд производит промежуточный вывод по теме JMSReplyTo, НО вывод представляет собой неупорядоченный объект MyRequest, в результате которого возникает исключение «ClassNotFoundException: (имя пакета) .MyRequest», что очевидно, поскольку это только класс, используемый в моей внутренней обработке - я не хочу выводить это в тему вывода. Похоже, что Camel неявно использует назначение JMSReplyTo между requestProcessor и обработкой messageSplitter ... Почему? Что я делаю неправильно? Каковы лучшие практики?