Request to allow non-JMS compliant property types to be set on JMS Message in camel-jms

This is a request to allow non-JMS compliant property types to be set on a JMS message in camel-jms.

When camel-jms constructs a JMS message, it parses all the messages headers on the Camel Exchange's IN message and tries to set these as message properties on the JMS message.

The relevant code is in class org.apache.camel.component.jms.JmsBinding.

The call to method appendJmsProperty() invokes

Object value = getValidJMSHeaderValue(headerName, headerValue);

Now, that method is implemented as

   protected Object getValidJMSHeaderValue(String headerName, Object headerValue) {
        if (headerValue instanceof String) {
            return headerValue;
        } else if (headerValue instanceof BigInteger) {
            return headerValue.toString();
        } else if (headerValue instanceof BigDecimal) {
            return headerValue.toString();
        } else if (headerValue instanceof Number) {
            return headerValue;
        } else if (headerValue instanceof Character) {
            return headerValue;
        } else if (headerValue instanceof CharSequence) {
            return headerValue.toString();
        } else if (headerValue instanceof Boolean) {
            return headerValue;
        } else if (headerValue instanceof Date) {
            return headerValue.toString();
        }
        return null;
    }

By returning null for any non JMS compliant message header types we enforce that only JMS compliant property types are used in this method. I can understand the motivation.

However I was wondering if we could open this up?
Its already the responsibility of the JMS provider to accept only supported types for message properties and raise an exception if a type is not supported.
However it seems certain JMS providers offer additional non-JMS compliant properties to be set (like WMQ allows to set an MQ accounting token of type byte[])

With the code above its impossible to utilise any non-JMS compliant property types.

Why could we not be more open and try to set any kind of message property type on the JMS Message (e.g. via Message.setObjectProperty()) and leave it to the JMS provider to raise an exception if an unsupported type is passed along? In such case the provider would raise an exception which we could catch and deal with right in method JmsBinding.appendJmsProperty().

The big benefit of this approach would be that we offer users to set any kind of proprietary and non-JMS compliant properties on a JMS message that may turn on additional features offered by the provider.

What's the opinion of our Camel experts here? Do we want to remain very strict and only allow JMS compliant property types (even if provider supports additional types) or could we potentially open this up and allow any type a provider supports?
Again the benefit would be that customers can use additional provider specific features like this WMQ accounting token.

I think the code changes would be small, mainly in class JmsBinding and related unit tests.