Add support for configuring non-standard JMS acknowledge modes

[vpavic]

Prior to this commit, spring.jms.listener.acknowledge-mode and
spring.jms.template.acknowledge-mode accepted only a predefined set of
values representing standard JMS acknowledge modes.

This commit adds support for also using arbitrary integer values to
these configuration properties, which allow configuring vendor-specific
JMS acknowledge modes.

Closes #37447

---

Note that this PR depends on #37500 (which adds support for spring.jms.template.acknowledge-mode).

This PR also wraps up efforts started in #37473 that aim to improve developer experience when working with JMS vendors such as SQS, which provides non-standard acknowledge modes and doesn't support transactions

[wilkinsona]

Thanks for the PR, @vpavic. I've rebased this on the latest change in main and tried adding a test:

@Test
void testJmsListenerContainerFactoryWithNonStandardAcknowledgeMode() {
	this.contextRunner.withUserConfiguration(EnableJmsConfiguration.class)
		.withPropertyValues("spring.jms.listener.session.acknowledge-mode=9")
		.run((context) -> {
			DefaultMessageListenerContainer container = getContainer(context, "jmsListenerContainerFactory");
			assertThat(container.getSessionAcknowledgeMode()).isEqualTo(9);
		});
}

It fails:

java.lang.IllegalArgumentException: Only values of acknowledge mode constants allowed
	at org.springframework.util.Assert.isTrue(Assert.java:111)
	at org.springframework.jms.support.JmsAccessor.setSessionAcknowledgeMode(JmsAccessor.java:170)
	at org.springframework.jms.config.AbstractJmsListenerContainerFactory.createListenerContainer(AbstractJmsListenerContainerFactory.java:235)
	at org.springframework.boot.autoconfigure.jms.JmsAutoConfigurationTests.getContainer(JmsAutoConfigurationTests.java:271)
	at org.springframework.boot.autoconfigure.jms.JmsAutoConfigurationTests.lambda$9(JmsAutoConfigurationTests.java:168)
	at org.springframework.boot.test.context.runner.AbstractApplicationContextRunner.accept(AbstractApplicationContextRunner.java:434)
	at org.springframework.boot.test.context.runner.AbstractApplicationContextRunner.consumeAssertableContext(AbstractApplicationContextRunner.java:363)
	at org.springframework.boot.test.context.runner.AbstractApplicationContextRunner.lambda$1(AbstractApplicationContextRunner.java:341)
	at org.springframework.boot.test.util.TestPropertyValues.lambda$5(TestPropertyValues.java:174)
	at org.springframework.boot.test.util.TestPropertyValues.applyToSystemProperties(TestPropertyValues.java:188)
	at org.springframework.boot.test.util.TestPropertyValues.applyToSystemProperties(TestPropertyValues.java:173)
	at org.springframework.boot.test.context.runner.AbstractApplicationContextRunner.lambda$0(AbstractApplicationContextRunner.java:341)
	at org.springframework.boot.test.context.runner.AbstractApplicationContextRunner.withContextClassLoader(AbstractApplicationContextRunner.java:369)
	at org.springframework.boot.test.context.runner.AbstractApplicationContextRunner.run(AbstractApplicationContextRunner.java:340)
	at org.springframework.boot.autoconfigure.jms.JmsAutoConfigurationTests.testJmsListenerContainerFactoryWithNonStandardAcknowledgeMode(JmsAutoConfigurationTests.java:167)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)

Apologies if I have introduced the problem while rebasing but I don't think I have. It looks to me like further Framework changes are required to support this.

[vpavic]

After taking a quick look, it appears that this is caused by a regression in Spring Framework introduced in spring-projects/spring-framework@3b8dd0a. Prior to that commit, JmsAccessor#setSessionAcknowledgeMode wasn't constrained to only standard acknowledge modes - I have several Spring Boot 3.1 based projects that are using SQSSession.UNORDERED_ACKNOWLEDGE.

I'll open an issue against Framework shortly.

[vpavic]

Instead of an issue, I've opened spring-projects/spring-framework#31328 to address the regression on the Framework side.

[vpavic]

With spring-projects/spring-framework#31328 merged, I assume this is now unblocked?

[wilkinsona]

Not quite. We'll move to snapshots next week so it's blocked until then.

[vpavic]

Is this expected to target 3.2? I'm asking because there's no assigned milestone.

[wilkinsona]

Hopefully, yes, but we'll have to see what time permits. I'll assign it to 3.x for now and we can hopefully pull it forwards.

[wilkinsona]

I've pushed my polishing: https://github.com/wilkinsona/spring-boot/tree/gh-37576.

However, I think we may need to take a different approach for a couple of reasons:

1. By moving away from an enum, we've lost the capabilities of LenientStringToEnumConverterFactory. This means that values like dupsok will no longer work.
2. By doing the mapping when the property is used rather than when it's bound, the diagnostics won't be so good when the configuration is invalid

I'd like to discuss this with the rest of the team.