I refer to commit dd2b9fe93afafa61e1aa1f89832c151bfb35920c that enabled the Context interface to handle a ConfigurationEvent. Currently, there is only a method to register a ConfigurationEventListener. It would be useful to have another method to deregister such a listener. What's more, the current source describes the registration method as follows: "The propagation of {@link ConfigurationEvent configuration events} is intended for internal testing as well as some coordination between configurators." I believe a ConfigurationEvent is generally useful. The documentation should acknowledge that. BACKGROUND I use Logback in a Spring web application and need to register LoggingEvent filter beans programmatically. This requires to hook into Spring's lifecycle and to perform registration / deregistration on bean initialization and destruction. Special attention needs to be taken to Logback's configuration reload. In this case I need to hook into ReconfigureOnChangeTask to realize when reload has ended since all filter beans need to be registered again. This can be performed with the help of listeners, all of which have some drawbacks: * LoggerContextListener#onReset( context) : This fires before the Logback configuration file has been read and thus, before appenders are available. Registration of LoggingEvent filters is not possible here. * StatusListener#addStatusEvent( status) : Fires more often (on each status message). It is hard to realize the "end of configuration" state from just a message, a level and the notifying instance. This also does not seem like a stable and consistent solution to me. * ReconfigureOnChangeTaskListener#doneReconfiguring( ) : Could be the right choice but is currently unused, package-private and was probably never intended for general usage. * ConfigurationEventListener#listen( configurationEvent) : Seems to be ideal since one can identify the end of Logback's configuration (ConfigurationEvent#CONFIGURATION_ENDED). This, however, does not offer a method to deregister a corresponding listener. The point is I need to cleanup resources on shutdown of Spring's ApplicationContext because Logback's LoggerContext is a shared singleton that survives Spring. It should be easy to add a deregistration method here. Any opinion / suggestion? Regards, Mathias