4 Replies Latest reply on Aug 5, 2009 10:03 AM by Kevin Conner

    Should JmsCourier be allowed to overwrite outgoing JMS Messa

    Daniel Bevenius Master

      Jira: https://jira.jboss.org/jira/browse/JBESB-2771

      When a JmsCourier is created and is specified to be a sender (isReciever=false), the passed in JMSEPR's message selectors is stored in a field (_messageProperties which is a List of KeyValuePairs).

      When this JmsCourier is going to deliver a JMS Message it will iterate through the properties and set them on the outgoing JMS Message:

      for (KeyValuePair kvp : _messageProperties) {
       String key = kvp.getKey();
       if(message.getStringProperty(key) == null) {
       message.setStringProperty(key, kvp.getValue());
      }

      The problem here is that the current implementation will first check to see if the JMS Message already has a property with the same key set on it, and if it has, will not overwrite the value.

      This is a problem because before this is done the JMSPropertiesStrategy will have been run and might for example have set the 'jbossESBresponseUUID' causing and old and invalid message selector to be passed through.
      This can be fixed by letting the JmsCourier have the last say and overwrite message properties. Or an explicit check could be add for 'jbossESBresponseUUID'.

      Any thoughts on this?

      Thanks,

      /Daniel



        • 1. Re: Should JmsCourier be allowed to overwrite outgoing JMS M
          Kevin Conner Master

          Have you got an example which shows this going wrong? It may help us to understand better if we can see the issue first hand.

          If this is specific to the transport then we should aim to have the transport clean it up before the message is delivered and not have it leak through. Can you see an easy way to do this?

          Kev

          • 2. Re: Should JmsCourier be allowed to overwrite outgoing JMS M
            Kevin Conner Master

            From looking through the code there may be a couple of things that need to be tidied up.

            The DefaultJmsReplyToEpr seems to be creating a selector based on a previous EPR selector but this seems to be unnecessary, it would appear to be sufficient just to include the jbossESBresponseUUID as the selector. Does anyone know why this was done?

            As for hiding it, perhaps it is sufficient to include a check for the jbossESBresponseUUID property in the DefaultJMSPropertiesSetter. In this way we could treat it in the same manner as JMSX and JMS_ properties.

            Kev

            • 3. Re: Should JmsCourier be allowed to overwrite outgoing JMS M
              Daniel Bevenius Master

               

              Have you got an example which shows this going wrong?

              The example here is an action that uses the ServiceInvoker to call another service in the ESB. This called service uses a MEP (Message Exchange Pattern) of 'RequestResponse'.
              Having multiple of these actions in the pipeline would cause the 'jbossESBresponseUUID' to stay unchanged, which will cause message pickup to fail as there is no match for the new selector.

              If this is specific to the transport then we should aim to have the transport clean it up before the message is delivered and not have it leak through. Can you see an easy way to do this?

              We could set specify a filter pattern for the DefaultESBPropertiesSetter:
              /**
               * Filter pattern for incoming property keys. These are properties that should not be
               * extracted from the JMS Message object into the ESB Message object.
               */
              private static final String INPUT_PROPERTIES_FILTER = DefaultJmsReplyToEpr.REPLY_UUID_TAG;
              
              /**
               * Strategy for setting JMS Properties on the ESB Message object created
               * by the process method.
               */
              private ESBPropertiesSetter esbPropertiesStrategy = new DefaultESBPropertiesSetter(INPUT_PROPERTIES_FILTER);
              



              • 4. Re: Should JmsCourier be allowed to overwrite outgoing JMS M
                Kevin Conner Master

                 

                "beve" wrote:
                The example here is an action that uses the ServiceInvoker to call another service in the ESB.


                Yeah, it took me a bit to follow it through in the code but I think I am there now :).

                "beve" wrote:
                We could set specify a filter pattern for the DefaultESBPropertiesSetter

                Yes, that would be the right place for it and not DefaultJMSPropertiesSetter as I had wrongly stated previously :)

                Kev