This is a demo application that is not fully functioning. It is supposed to give a general idea of the configured codebase in order to convey possible errors.
The broker this application connects to is a Wildfly application server (Version 10). The Queues and Topics that are listened to already do exist in the Wildfly. This application only connects to them.
The used dependency versions are being provided transitively via Spring Boot 3.5.3 (ActiveMQ Artemis 2.40.0).
When initially starting this application (which, again, is not fully functional and only serves as a code-example) the topic-JmsListener subscribes to the topic. This subscription persists across both Spring Boot application restarts as well as Wildfly restarts.
When shutting down the Spring Boot application in order to only change the selector of the topic-JmsListener, the consumer-creation logic in ActiveMQ Artemis interprets this changed listener as a new one and tries to unsubscribe the "old" one on restart.
This leads to this line being called within the ActiveMQSession that tries to delete the queue only if the Queue is not managed (by the Wildfly application).
This check fails because the configurationManaged field contains a null value, which I assume is connected to the old Wildfly version used.