Announcement Announcement Module
No announcement yet.
DefaultMessageHandler vs. AggregatingMessageHandler Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • DefaultMessageHandler vs. AggregatingMessageHandler

    I like the feature that the MessageHeaders from an incoming message is copied to the outcoming message by the DefaultMessageHandler.

    In case I have an Aggregator where several incoming messages are collected in a list the returned message does not copy the headers.

    On one hand it makes sense since there are several input messages. On the other hand I assume that under normal circumstances the headers for all incoming messages should be the same?! In this case it would be sufficient to copy the headers from the first message in the list. Or: to copy all headers for the output message. This would be somehow an aggregation of all headers for the output message.

    Does that make somehow sense?

    Thanks Tai

  • #2
    As a conclusion: you cannot rely that the MessageHeaders are transported through the whole integration flow when using an aggregator!

    This is really a pain. As a workaround in my aggregator endpoint I have to programatically get the header from my incoming messages (use any header since I can assume it is the same for all messages) and return a message with that header!

    The problem is that the result message (and not the incoming messages) is passed to the MessageBuilder:
    public class AggregatingMessageHandler extends AbstractMessageBarrierHandler {
    	protected Message<?>[] processReleasedMessages(Object correlationId, List<Message<?>> messages) {
    		if (result.getHeaders().getCorrelationId() == null) {
    			result = MessageBuilder.fromMessage(result)
    		return new Message<?>[] { result };


    • #3

      As you just observed, it's not safe to assume on a general basis that the message headers of the aggregated Messages are the same, therefore using values from an arbitrary message in the sequence (first or last for example) would be unsafe. Copying the common values is not safe either.

      In that light, this is the kind of concern which is best left to the user of the framework. In your case, instead of extending AggregatingMessageHandler (which has been refactored, btw) you could simply return a Message<?> object from your Aggregator, and take care of composing the appropriate header inside that.

      Hope that helps,


      • #4
        Hi Marius,

        Actually I did programatically changed my Aggregator instead of extending AggregatingMessageHandler. Though I still think this isn't the cleanest solution.

        Basically you are saying:
        - for all endpoints: the incoming message header is copied to the outcoming message
        - except for the Aggregator!

        The current implementation increases the complexity in the whole integration flow! Every Aggregator has to take care for transporting the proper headers. In case I am re-using this integration for another customer-specific implementation I need to check in all sub-classes which additional headers might have been added to change my Aggregator as well.

        Wouldn't it make sense to also aggregate/merge all incoming message headers to the outcoming message? In my case all incoming message headers are the same. Don't you think this is the normal case?

        On the other hand there is no black or white. Meaning both should be allowed: merge all or copy nothing.

        I think it would be very nice when the SI API allows both. A possibility is to attach for each header key whether it is static/persistent or dynamic/transient. In this case the MessageHandler can always copy the persitent message keys!

        Just my 2 cents about it.