We are looking into using the JmsListenerEndpointRegistry to dynamically register and unregister listener containers during the runtime of the application. However, unregistering a container is currently not possible in the moment. Is there a reason for this? Is it possible to add a method that would allows us to unregister a container in a similar way as you can register one?

If something like this is accepted by the team I am willing to do a PR to add the functionality.

Comment From: snicoll

The registry is not really meant for such access (per the class Javadoc). JmsListenerConfigurer is alongside JmsListenerEndpointRegistrar. Note the name here that implies that it is about registration (and only that). Hopefully that explains why the registry doesn't expose an unregister.

The current arrangement is application context lifecycle based. If we wanted to offer what you're building, we'd probably have to offer other high-level contract. Failing that, I think the API would be inconsistent.

Having said all of that, you can get a listener out of the registry and stop it yourself. Is that because you'd like to reuse the id or you're using the id as a way to know if something is registered? Either way, I think the current API lets you implement whatever you need with little efforts so I'd like to hear first what the concrete problem is.

Comment From: filiphr

The registry is not really meant for such access (per the class Javadoc). JmsListenerConfigurer is alongside JmsListenerEndpointRegistrar. Note the name here that implies that it is about registration (and only that). Hopefully that explains why the registry doesn't expose an unregister.

As far as I understood it the JmsListenerEndpointRegistrar is a helper bean for registering @JmsListener endpoints (per the Javadoc). However, from my understanding it is not really a Spring Bean that can be injected (maybe I have missed something), and it is used by the JmsListenerAnnotationBeanPostProcessor.

The current arrangement is application context lifecycle based. If we wanted to offer what you're building, we'd probably have to offer other high-level contract. Failing that, I think the API would be inconsistent.

Indeed the registry is a SmartLifecycle bean, which offers us a lot of infrastructure management such as the destruction of the beans when the container stops. On the other side it also allows for dynamic registration of JmsListenerEndpoint by passing true to the startImmediatelly to the registerListenerContainer. We would still like to continue to use the fact that the registry stops all the containers when the application context closes.

Having said all of that, you can get a listener out of the registry and stop it yourself. Is that because you'd like to reuse the id or you're using the id as a way to know if something is registered? Either way, I think the current API lets you implement whatever you need with little efforts so I'd like to hear first what the concrete problem is.

Yes I saw that I can get it by the id and stop it. However, it would stay in the list and I won't be able to reuse its id. Our main goal is to reuse the id of the container.

To give some more context, we are adding some new functionality to Flowable with an event registry that would allow you to receive events via different channels (JMS, RabbitMQ, Kafka) and trigger Processes / Cases. We would make this registration dynamic, such that it would be possible for people to update the definitions (they would be persisted in the database) for the incoming channels during the runtime of the application without a restart of the server via REST. When a definition is updated we would need to unregister the previous one and register a new JmsListenerEndpoint. Every definition has a human readable unique key, in order for it to be consistent across different environments. The fact that the current API offers us to implement this functionality with little effort is why we've decided to base this on spring-jms, spring-rabbit and spring-kafka respectively.

We would take care of the dynamic registration and unregistration of a JmsListenerEndpoint when the definitions are updated, but we would like to leave the shutdown of the application context to Spring for this.

We also have outbound possibilities, such that you can send an event over a different channel (JMS, RabbitMQ and Kafka) and for this we are planning to use the respective templates offered by the Spring team.

I mentioned spring-rabbit and spring-kafka, which I know are not part of this project and have their own projects.

Comment From: snicoll

As far as I understood it the JmsListenerEndpointRegistrar is a helper bean for registering @JmsListener endpoints (per the Javadoc). However, from my understanding it is not really a Spring Bean that can be injected (maybe I have missed something), and it is used by the JmsListenerAnnotationBeanPostProcessor.

Did you miss the part that you quoted where I mentioned JmsListenerConfigurer is the way to programmatically register endpoints? It is also documented in a dedicated section.

The point I was trying to make is that there isn't a feature of registering and unregistering JMS endpoints at runtime. The infrastructure that we have is meant to register the endpoints on startup via configuration (again, via JmsListenerConfigurer and not calling the registry directly) and to make sure they are properly shutdown when the ApplicationContext stops.

Flagging to team attention to see what the team thinks of expanding the feature to allows registration (and unregistration) at runtime.

Comment From: filiphr

Did you miss the part that you quoted where I mentioned JmsListenerConfigurer is the way to programmatically register endpoints? It is also documented in a dedicated section.

Oh sorry, I didn't understand that you are referring to that and missed the documentation section about it. Thanks for pointing it out to me, this actually helps me with another use case that we have (not related to the one I previously described).

The point I was trying to make is that there isn't a feature of registering and unregistering JMS endpoints at runtime. The infrastructure that we have is meant to register the endpoints on startup via configuration (again, via JmsListenerConfigurer and not calling the registry directly) and to make sure they are properly shutdown when the ApplicationContext stops.

Thanks for the clarification. I was not going through the documentation, but through the code and I misunderstood things.

Thanks for looking into expanding the feature to allow registration (and unregistration) at runtime. We would very much like to use this for our use case. I am also willing to help out with the implementation if needed

Comment From: sbrannen

Closing due to lack of community interest, but this issue may potentially be revisited at a later date.