Uploaded image for project: 'Red Hat Fuse'
  1. Red Hat Fuse
  2. ENTESB-7220

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

    XMLWordPrintable

    Details

    • Type: Enhancement
    • Status: Closed
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: jboss-fuse-6.2.1, jboss-fuse-6.3
    • Fix Version/s: fuse-7.0
    • Component/s: Camel
    • Environment:

      camel-jms

    • Sprint:
      7.0 Sprint 17 - Tech Preview 1

      Description

      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.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  oscerd Andrea Cosentino
                  Reporter:
                  mielket Torsten Mielke
                  Tester:
                  Viliam Kasala
                • Votes:
                  2 Vote for this issue
                  Watchers:
                  7 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: