JMS Endpoints should allow dynamic destination name

[gucce]

Problem

Currently, a JMS endpoint in Citrus (2.7.1) is defined with a static destination-name like this:

<citrus-jms:endpoint id="someJmsEndpoint"
                     destination-name="some.queue"
                     connection-factory="someConFactory"/>

This is problematic if you have tests with lots of different queues which all use the same connection factory. For every queue you need to define a separate endpoint even if only the queue name is different.

Moreover, it is impossible to send messages to a queue whose name is only known at runtime.

Solution

Include a dynamic endpoint header to the JMS endpoint, similar to the HTTP one:

<header>
   <element name="citrus_endpoint_uri"	
            value="http://localhost:${port}/${context}"/>
</header>

Example

<send endpoint="someJmsEndpoint">
    <message>
        ...
    </message>
    <header>
        <element name="citrus_jms_destination_name"	
                 value="some.other.queue"/>
    </header>
</send>

[gucce]

👍 Thanks for the implementation!

[gucce]

I updated my test code to use Citrus 2.7.2 and wanted to use this feature. I have noticed that the dynamic destination resolver is only used in send actions (JmsProducer) and not in receive (JmsConsumer) actions.
However, being able to set a dynamic destination in receive actions is equally important as doing so in send actions.

Thus, the DestinationNameResolver should also be used in receive actions.

[gucce]

I've digged through the code and realized that it's not easy to support the special header citrus_jms_destination_name for receive actions.
The headers are part of the message Object, which obviously has not yet been created in the receive method. So in case of a receive action the mechanism to extract the special header would have to work differently.
We'd need to somehow extract the header from the validation headers which are also not accessible in the JmsConsumer.
Theoretically, we could use the JMS selector, but I think this would be ugly.

[gucce]

As a workaround you can use the following syntax, see Citrus documentation - Dynamic Endpoints:

<receive endpoint="jms:Hello.Response.Queue?timeout=5000">
    ...
</receive>

This also works for sync JMS like this: jms:sync:Hello.Response.Queue

[christophd]

I think using dynamic endpoints here is the best solution. As you already mentioned accessing the dynamic endpoint resolver is not easy for receive operations due to design limitations. Will close this issue if no further objections.

[gucce]

👍