RFR: 8043306 - Provide a replacement for the API that allowed to listen for LogManager configuration changes
jason_mehrens at hotmail.com
Fri Sep 12 15:39:01 UTC 2014
I suppose that the propagating uncaught exceptions to the caller was the previous behavior of the old property change methods but it seems out of place for the LogManager. The LogManager is a global resource so broken listener code in web app A could suppress notifications in web app B and C. That doesn't seem very nice. A lot of the LogManager code handles exception via catch, report or ignore, and continue when dealing with handlers etc. I would think that same strategy applies here too.
> Date: Fri, 12 Sep 2014 16:59:03 +0200
> From: daniel.fuchs at oracle.com
> To: Alan.Bateman at oracle.com
> Subject: Re: RFR: 8043306 - Provide a replacement for the API that allowed to listen for LogManager configuration changes
> CC: core-libs-dev at openjdk.java.net
> On 9/12/14 4:42 PM, Alan Bateman wrote:
>> On 12/09/2014 15:16, Daniel Fuchs wrote:
>>> Thanks Alan!
>>> I have updated the webrev with your suggestions:
>>> -- daniel
>> A minor suggestion for readConfiguration is that "Any register
>> configuration listeners .." might be a bit better than "The
>> configuration listeners ...".
>> In addConfigurationListener there is a <br> between the two sentences
>> that talk about exceptions, I don't know if you intended that.
> Done. I regenerated the webrev in place.
> -- daniel
>> Otherwise the javadoc looks good to me.
More information about the core-libs-dev