Allow byte[] class to be mapped from DefaultJmsHeaderMapper

[RogerLapin]

Expected Behavior

When a message (produced by IBM MQ) comes through (eg) a message-driven-channel adapter (or any adapter that will use DefaultJmsHeaderMapper), it will map any (non-JMS) fields whose type belongs to SUPPORTED_PROPERTY_TYPES.
It include IBM Byte arrays (MQBYTE24 and LMQBYTE32 )

Current Behavior

When a header of the incoming message is of type byte[], it will be ignored because it is not part of SUPPORTED_PROPERTY_TYPES.

Context

This is a problem when you need to transmit some MQBYTExx headers that must remain untouched and send as MQMD headers (and not JMS). For example, JMS messageId will not be retained by a target MQ Series broker, and will be replaced by a new generated one. This makes the pattern REQUEST/REPLY (based on msgId / CorrelId) fail.

Our current workaround is to take over the mapper through a customized one.

Exemple of the workaround for IBM MQMD MsgID

public class MqCompatibleJmsHeaderMapper extends DefaultJmsHeaderMapper {
...
  public void fromHeaders(MessageHeaders headers, Message jmsMessage) {
	Object messageId = headers.get(WMQConstants.JMS_IBM_MQMD_MSGID);
	if(messageId !=null) {
		if (messageId instanceof byte[]) {
			jmsMessage.setObjectProperty(WMQConstants.JMS_IBM_MQMD_MSGID, messageId);
		}else  {
		 ...
		}
	}
	super.fromHeaders(headers, jmsMessage);
  }

...
}

[artembilan]

We decided to not back-port to the previous version since it turned out an ActiveMQ does not support a byte[] unlike Artemis we use in the current 6.0 to support Jakarta EE.
At least we know that workaround is simple if byte[] mapping is supported and required.