Queues property is not correctly resolved on the @org.springframework.amqp.rabbit.annotation.RabbitListener class

[novtor]

When the "queues" value is configured via application.yml with conditionals inside, it is not correctly resolved
RabbitListenerIssue.zip

[novtor]

I think, the issue is in this file:

spring-amqp/spring-rabbit/src/main/java/org/springframework/amqp/rabbit/annotation/RabbitListenerAnnotationBeanPostProcessor.java

Line 729 in ffff7d7

if (!(resolvedValue.startsWith("#{") && value.endsWith("}"))) {

should be replaced by
if (!(resolvedValue.**contains**("#{") && value.**contains**("}"))) {

[artembilan]

I think you have a point here!

Indeed the TemplateAwareExpressionParser used from the StandardBeanExpressionResolver parses the first aaa.bbb. part as LiteralExpression and the next part with the #{...} as a SpelExpression to evaluation.

I've just tested and confirmed that we are good to go with your suggestion!

@RabbitListener(queues = "test.#{'simple'}", group = "testGroup")

But that's only the part of the solution for your. Since your expression is very complex there, you should be careful with all the required symbols to honor SpEL syntax.

For now I'd suggest you as workaround as:

amqp:
  queue:
    suffix: 001
    name: #{'aaa.bbb.' + '${amqp.queue.suffix}' == '001' ? 'default': '${amqp.queue.suffix}'}

Pay attention to single quotes everywhere. Since after resolving the property placeholder, the result becomes something valuable for the SpEL and tries to be resolved against application context. As far as they all are literals they have to be quoted. Not sure though if a single quote ' will be enough: https://docs.spring.io/spring-cloud-dataflow/docs/1.3.0.M2/reference/htmlsingle/#shell-white-space. But it worth to try!

Feel free to come back to us with the contribution on the matter!

[garyrussell]

I don't think changing it contains(() is the right solution.

I think we should simply document that the SpEL evaluation is done after the property placeholder resolution and must match the regex pattern ^#{...}$.

My 2c.

[artembilan]

Gary, one more time.

The TemplateAwareExpressionParser is able to parse an expression like foo.#{myBean.x}.bar to the CompositeStringExpression: LiteralExpression, SpelExpression, LiteralExpression. Just because it has a logic like:

	while (startIdx < expressionString.length()) {
			int prefixIndex = expressionString.indexOf(prefix, startIdx);
			if (prefixIndex >= startIdx) {
				// an inner expression was found - this is a composite
				if (prefixIndex > startIdx) {
					expressions.add(new LiteralExpression(expressionString.substring(startIdx, prefixIndex)));
				}

That CompositeStringExpression does exactly string concatenation under hood:

for (Expression expression : this.expressions) {
	String value = expression.getValue(String.class);
	if (value != null) {
		sb.append(value);
	}
}

I would even say that we don't need that condition to check if that contains expression tokens or not.
We always can rely on the TemplateAwareExpressionParser and get a simple LiteralExpression for non-templated string. Well, that is actually what is done by Spring per se. See AbstractBeanFactory.doResolveBeanClass() for example:

String className = mbd.getBeanClassName();
		if (className != null) {
			Object evaluated = evaluateBeanDefinitionString(className, mbd);
			if (!className.equals(evaluated)) {

So, I would even say that with the current logic we even restrict the user in possible expression variants.

Well, I may see your concern to make such a change in the current GA release, but we definitely should reconsider it in the next 2.1.0 or even in the point 2.0.1 version.

FYI. I have just commented out the code:

if (!(resolvedValue.startsWith("#{") && value.endsWith("}"))) {
	return resolvedValue;
}

And all our tests are passing.