New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JMS Endpoints should allow dynamic destination name #256

Closed
gucce opened this Issue Jun 13, 2017 · 6 comments

Comments

Projects
None yet
2 participants
@gucce
Contributor

gucce commented Jun 13, 2017

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>

@christophd christophd added the READY label Jun 13, 2017

@christophd christophd added this to the v2.7.2 milestone Jun 13, 2017

@christophd christophd added IN PROGRESS and removed READY labels Jun 28, 2017

@christophd christophd self-assigned this Jun 28, 2017

@christophd christophd removed the IN PROGRESS label Jun 29, 2017

@gucce

This comment has been minimized.

Contributor

gucce commented Jun 30, 2017

👍 Thanks for the implementation!

@gucce

This comment has been minimized.

Contributor

gucce commented Jul 28, 2017

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 gucce reopened this Jul 28, 2017

@gucce gucce assigned gucce and unassigned christophd Jul 31, 2017

@gucce

This comment has been minimized.

Contributor

gucce commented Aug 4, 2017

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.

@christophd christophd added the READY label Sep 12, 2017

@gucce

This comment has been minimized.

Contributor

gucce commented Oct 5, 2017

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

This comment has been minimized.

Member

christophd commented Oct 5, 2017

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

This comment has been minimized.

Contributor

gucce commented Oct 6, 2017

👍

@gucce gucce closed this Oct 6, 2017

@christophd christophd removed the READY label Oct 6, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment