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
_______________________________________________
logback-dev mailing list
logback-dev@qos.ch
https://mailman.qos.ch/cgi-bin/mailman/listinfo/logback-dev
