Skip to content
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

Runtime resolution of destinations [SPR-12289] #16894

Closed
spring-issuemaster opened this issue Oct 2, 2014 · 6 comments
Closed

Runtime resolution of destinations [SPR-12289] #16894

spring-issuemaster opened this issue Oct 2, 2014 · 6 comments

Comments

@spring-issuemaster
Copy link
Collaborator

@spring-issuemaster spring-issuemaster commented Oct 2, 2014

Stéphane Nicoll opened SPR-12289 and commented

Annotated endpoints such as @JmsListener requires the destination to be set in the code. It is possible to externalize that value to a property using a placeholder but that information is mandatory.

It would be nice to be able to resolve the destination to use at runtime.


Affects: 4.1 GA

3 votes, 5 watchers

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Oct 2, 2014

Stéphane Nicoll commented

Since this is a cross-cutting concerns (AMQP resolves a list of queue(s)) we should probably try to create an abstraction for that in spring-messaging or something.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Oct 16, 2014

Andrew Landsverk commented

I am all for allowing this to be externalized to a placeholder, that would greatly aide in our use case of being able to specify a different queue name in different environments.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Oct 16, 2014

Stéphane Nicoll commented

Some confusion here maybe Andrew. You can already do that. If you have some PropertySource with PropertySourcesPlaceholderConfigurer you can write @JmsListener(destinations = "${some.key}") which will match the value of some.key

We're talking about a more advanced option where you could resolve the destination to use at runtime based on whatever code you might have.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Oct 16, 2014

Andrew Landsverk commented

Ahh yes, my apologies, carry on. :)

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Apr 20, 2015

Stéphane Nicoll commented

Actually, both inbound and outbound messages can be resolved via a DestinationResolver and both values can use an expression if required. If that still does not fit, setting a DestinationResolver seems like an obvious candidate. Actually, creating yet another interface to resolve destinations will not ease readability.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Jan 25, 2017

Floris Kraak commented

Well, DestinationResolver doesn't solve listening to queues that did not exist when the application started.

So it's about listening to new queues or topics on the fly while the application is running.
That is possible, it's just not very intuitive.

The proof of concept I'm working on does it like this:

public void configureJmsListenerFor(String topicname, JmsListenerEndpointRegistry registry, ConnectionFactory connectionFactory) {

	DefaultJmsListenerContainerFactory factory = createFactory();
	factory.setClientId(String.format("poc-client-%s", topicname));
	factory.setConnectionFactory(connectionFactory);
	registry.registerListenerContainer(createJmsListenerFor(topicname), factory, true);
}

private DefaultJmsListenerContainerFactory createFactory() {
DefaultJmsListenerContainerFactory factory = new DefaultJmsListenerContainerFactory();
factory.setPubSubDomain(true);
factory.setSubscriptionDurable(true);
return factory;
}

and the main method then does:

QueuepocApplication application = context.getBean(QueuepocApplication.class);
JmsListenerEndpointRegistry registry = context.getBean(JmsListenerEndpointRegistry.class);
ConnectionFactory connectionFactory = context.getBean(ConnectionFactory.class);
application.configureJmsListenerFor(TOPIC, registry, connectionFactory);

If there's a better interface for that, I'm all ears.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.