Похоже, я имел дело с точно такой же проблемой в течение последних двух дней. Я верю, что уже решил это. Вот что я узнал:
Кажется, что NPE в StaxUtils вызван source
(javax.xml.transform.Source
), равным null
. это может быть null
, когда exchange.getIn().getBody(Source.class)
возвращает null
в классе NMRDestination
. Здесь вещи становятся немного уродливыми. Давайте сделаем шаг назад.
Чтобы увидеть, было ли ваше сообщение, когда оно пришло, вам нужно включить TRACE
уровень журнала. Вы можете сделать это в консоли servicemix с помощью команды log:set TRACE
. ExchangeUtils#display(Exchange)
вызывается только с возможностью распечатать тело в TRACE, даже в DEBUG. С TRACE вы увидите такие вещи, как:
id: 1520804564-51998-1331328769981-0-3
mep: InOut
status: Active
role: Consumer
target: ...
properties: [ ]
In: [
content:
]
раздел In.content
по сути является телом сообщения. Я уверен, что у твоего обмена было тело, как у меня. Это означает, что он был «потерян» где-то в схеме маршрутизации ЯМР / Camel.
exchange.getIn().getBody(Source.class)
проходит специальную логику преобразования, которая может молча (!) Возвращать ноль, если что-то не щелкает. Посмотрите на org.apache.camel.impl.converter.BaseTypeConverterRegistry#doConvertTo()
.
Когда я читал журналы TRACE, я заметил еще одно тонкое (почти к сведению) сообщение о том, что org.apache.xml.serializer.ToXMLStream
не виден моему пакету. Я подумал, что ЯМР не смог преобразовать сообщение в исходный объект и ничего не сказал мне об этом.
РЕШЕНИЕ : я закончил тем, что добавил org.apache.xml.serializer
к своей инструкции Import-Package
maven вместе с org.apache.xalan
(как только я добавил импорт сериализатора, следующей вещью, которая взорвалась, было ClassNotFountException
жалоб 1034 *). Все есть во время выполнения, все это в lib/endorsed
, это просто не было видно для моего пакета услуг до сих пор.
Теперь это работает, и мое сообщение находится в конечной точке назначения. Еще одна вещь, на которую следует обратить внимание - это атрибут streamCache
содержимого Camel. Есть что-то в том, что потоковые ресурсы не кэшируются по умолчанию в последних версиях Camel, и ваш код не сможет читать из потока несколько раз, пока он не будет кэширован.
Остается вопрос: почему я должен информировать службу об этих зависимостях? ЯМР / Верблюд должен отправить мое сообщение по маршруту. Не имеет смысла.