Constructing a GenericMessage

[vavramov2]

It is common to have to keep the header of a message as it goes through the flow: E.g. pick up a message from the bus, apply command, and post downstream.

It would be great if there was another constructor to GenericMessage which takes a message as its argument and essentially clones it (e.g. copies over the payload + header). The copy can be deep or not.

[Mark Fisher]

Thanks for the suggestion. There are several use cases where I have realized that a copy constructor will be necessary. I have officially added the Jira issue: http://jira.springframework.org/browse/INT-123

[vavramov2]

Great -- thanks.

[vavramov2]

If there is no reason not to, please also make it Serializable.

[vavramov2]

Thanks Mark -- I see the new constructor and the fact that you are using it when calling createReplyMessage() in AbstractMessageHandlerAdapter.

Now I think I am down to only two big issues:
1) Please allow for the injection of a ReplyHandler inside the DefaultMessageEndpoint: I need to write a custom one which blocks, so that the JMSSession stays open and I can then stream results to the tempQueue specified within a JMSReplyTo on an incoming message
2)Would it not make sense to have JmsMessagePreProcessor? This way, we can pick out properties from the incoming transport prior to creating the spring message and put them in its header. Currently, I can override the SimpleMessageConverter and SimpleMessageMapper, but it is a bit clunky.


If there is another way to do this, please advise.

[Mark Fisher]

Thanks - both are excellent suggestions.

I would like to revisit your blocking replyHandler scenario alongside some other similar things that are planned for M3. I think we can provide a more elegant solution for cases where blocking and transaction coordination are necessary (this will be a major focus of M3). In the meantime, I think exposing a setter for 'replyHandler' does make sense (and would be consistent with the setter for 'errorHandler'): http://jira.springframework.org/browse/INT-129

For the 2nd issue, that is exactly what we have been discussing... essentially, the mapping consists of 2 tasks: map to/from payload and populate/extract header info. After working with adapters a bit, I am also inclined to separate the source and target when it comes to mapping. For example, we should provide a SourceMapper and a TargetMapper. Each can delegate to 2 strategies - for mapping the 1) payload and 2) header. Even though most implementations would actually implement both interfaces, this seems to be a more developer-friendly breakdown of the tasks at hand. As you mentioned, overriding the MessageConverter and MessageMapper currently feels clunky.

Thanks for the feedback!

[Mark Fisher]

This first issue mentioned above (http://jira.springframework.org/browse/INT-129) has now been resolved. If you get a chance to try it out, please let us know how it goes.

Thanks,
Mark

[vavramov2]

Thanks for the super quick turnaround. I tested it and it works; I saw that you even provided the SI namespace. I am really looking forward to m3.

Related to the issue of custom reply handler, here's some follow up. I know you're going to be revisiting that in m3, so I would like to understand whether the following will be handled:

Currently, we implemented a reply handler in the following way:

Destination d = (Destination)originalMessageHeader.getAttribute(Jm sTargetAdapter.JMS_REPLY_TO);
jmsTemplate.convertAndSend(d,replyMessage.getPaylo ad());

This of course means that my replyhandler is very jms specific. Ideally, I would be given a reply message channel (along with the message and headers) during the handle() call so the handler could send to the channel:

replyChannel.send(replyMessage);

Would it be possible to have the framework manage the relationship between the reply-to destination specified in the incoming JMS message and a reply channel (created dynamically and given to the reply handler)?

To make matters even more complicated, I would really like to be given a channel backed by a ChannelAdapter which was dynamically constructed based on a specific replyTo object: e.g. a uri scheme such as "tcp://hostnameort" or a Destination object in the case of JMS.

I hope this makes sense.