Creates the necessary MessageListenerContainer instances for the
registered endpoints. Also manages the
lifecycle of the listener containers, in particular within the lifecycle
of the application context.
Contrary to MessageListenerContainers
created manually, listener containers managed by registry are not beans
in the application context and are not candidates for autowiring.
Use getListenerContainers() if you need to access this registry's
listener containers for management purposes. If you need to access to a
specific message listener container, use getListenerContainer(String)
with the id of the endpoint.
Stop this component, typically in a synchronous fashion, such that the component is
fully stopped upon return of this method. Consider implementing SmartLifecycle
and its stop(Runnable) variant when asynchronous stop behavior is necessary.
Note that this stop notification is not guaranteed to come before destruction:
On regular shutdown, Lifecycle beans will first receive a stop notification
before the general destruction callbacks are being propagated; however, on hot
refresh during a context's lifetime or on aborted refresh attempts, a given bean's
destroy method will be called without any consideration of stop signals upfront.
Should not throw an exception if the component is not running (not started yet).
In the case of a container, this will propagate the stop signal to all components
Indicates that a Lifecycle component must stop if it is currently running.
The provided callback is used by the LifecycleProcessor to support
an ordered, and potentially concurrent, shutdown of all components having a
common shutdown order value. The callback must be executed after
the SmartLifecycle component does indeed stop.
The LifecycleProcessor will call only this variant of the
stop method; i.e. Lifecycle.stop() will not be called for
SmartLifecycle implementations unless explicitly delegated to within
the implementation of this method.
The default implementation delegates to Lifecycle.stop() and immediately
triggers the given callback in the calling thread. Note that there is no
synchronization between the two, so custom implementations may at least
want to put the same steps within their common lifecycle monitor (if any).