When sync endpoint and disableTempDesintations are used together JMSMessageDispatcher should return null rather than NullPayload

JmsTemporaryReplyToTestCase is failing for WMQ after the change.

Needed to update transports/wmq/src/test/resources/integration/jms-temporary-replyTo.xml in EE which overrides the CE config

https://dev.ee.mulesource.com/fisheye/changelog/products/?cs=17179

We changed all of the dispatchers to return NullPayload instead null. returning null short circuits all processing. No response transformers of further endpoints are processes. A endpoint should never return null. If this is breaking a test case, check the test case or code.

Dan F spent a lot of time fixing this for Atlas. please dont change stuff and break a lot of other functionality. I am at POC this is messing me up.

It looks like the change which Puneet is talking about was yours Dan:
http://fisheye.codehaus.org/changelog/mule/?cs=16181

And it seems to be very intentional based on the in-line comment:

// In this case a response was never expected so we return null and not NullPayload.
// This generally happens when dispatch is used for an asynchronous endpoint but can also occur when send() is used
// and disableTempDestinations is set.
return returnOriginalMessageAsReply ? new DefaultMuleMessage(msg) : null;

This is just for a single specific case after discussions with AP.

It is a regression. Run the attached test case against 2.4 and then against 2.5 snapshot. If regressions don't matter then I probably have to start using my own branch and build my own distributions.

No it is not. If you want the original message returned with JMSMessageID set, there's a returnOriginalMessage or similar flag for jms to do that. Check with Travis C for details.

I dont want the original message, I want the message from my transformer. I did not have to use this flag before and it used to work. why would using a newer version require me to change config. That is a regression cause it breaks a users existing code.

This is a minor regression compared to 2.2.3 yes, but it preserves the 2.2.2 behavior in this case where a response is not expected. In the cases where a response is expected NullPayload is returned and the previous improvement remains in place.

PG/AP: Maybe you can discuss this between you a bit?