Should JmsCourier be allowed to overwrite outgoing JMS Messa

[beve]

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

[kconner]

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

[kconner]

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

[beve]

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);

[kconner]

"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