Support Removal of ConfigurationEventListener

[mroeppis]

Originally published in the Logback-Dev Mailing list:

---

I refer to commit dd2b9fe 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.