camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Aksnes-NOR <>
Subject Strange problem when implementing a composed message processor
Date Wed, 28 Mar 2012 13:05:00 GMT
I am hitting some strange type problems when implementing a composed message processor using
a mixture of Camel and ActiveMQ
(Some of the ActiveMQ queues are served by .NET components) The actual processing is done
in a seda route called using ExchangePattern.InOut
(It is reused a couple of times)

* My incoming message is in a custom binary format coded as byte[]. This message is sent to
a .NET component using ActiveMQ and ExchangePattern.InOut.
* The return values are received as a Map.
* This map is then processed using a simple processor: Setting in.setBody(in.getBody(Map.class).entrySet(),Set.class)
 as well as setting a property for use as collation id later.
* The resulting set is then sent to split(body())
* Each of the parts is then processed individually then sent to an aggregator building up
a map. 
* This map is then sent to a second .NET component for result merging, done via ActiveMQ and
* The result from ActiveMQ looks ok, the length is what I expect the body type too (byte[])
This is the end of this route.
The calling route (a servlet route using ExchangePattern.InOut is doing this as calling this
seda route as its final component, but doesn't behave well at all.
 The problem being that the body type after exiting the seda route suddenly is java.util.HashMap.EntrySet
not byte[] as intended and as returned when invoking exchange.getIn().getBody().getClass().getCanonicalName()
in a processor at the end of the seda route. The only location where I use entry sets is early
in the route. Lots of changes in the body type are happening after that. Body type seems ok
at end of seda route but not just after getting the return value. As far as I know there are
no type converters matching these types around.

View raw message