RFR: 8043306 - Provide a replacement for the API that allowed to listen for LogManager configuration changes

Alan Bateman Alan.Bateman at oracle.com
Fri Sep 12 13:54:17 UTC 2014


On 12/09/2014 14:38, Daniel Fuchs wrote:
>
> Would modifying the specification of addConfigurationListener()
> as follows be sufficient to make the workings of the proposed
> implementation clearer?
>
>     /**
>      * Adds a configuration listener to be invoked each time the logging
>      * properties are read and the configuration is changed.
Would "... each time that the logging configuration is read" be 
sufficient? (just thinking that it might be more technically correct 
because the configuration might not have changed).


> * If the listener is already registered the method does nothing.
>      * <p>
>      * The order in which the listeners are invoked is unspecified.
That is okay, although it is the same as not saying anything :-)


> * <br>
>      * If a security manager is on, each listener will be invoked in the
>      * {@linkplain AccessControlContext security context} with which 
> it was
>      * registered.
An alternative is "The listener is invoked with privileges that are 
restricted by the calling context of this method".


> * <p>
>      * It is recommended that listeners do not throw errors or 
> exceptions.
>      * Exceptions or errors thrown by listeners will
>      * be propagated to the caller of {@link #readConfiguration()} (or 
> {@link
>      * #readConfiguration(java.io.InputStream)}) preventing those 
> listeners
>      * that haven't been invoked yet from being fired.
That seems okay. Here's a variation to consider:

"If a listener terminates with an uncaught error or exception then it 
will be propagated to the caller of readConfiguraiton and prevent other 
listeners from being notified".

-Alan.



More information about the core-libs-dev mailing list