Daniel,
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. Jason ---------------------------------------- > Date: Fri, 12 Sep 2014 16:59:03 +0200 > From: daniel.fu...@oracle.com > To: alan.bate...@oracle.com > Subject: Re: RFR: 8043306 - Provide a replacement for the API that allowed to > listen for LogManager configuration changes > CC: core-libs-dev@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: >>> >>> http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.04/ >>> >>> -- 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. > http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.04/ > > -- daniel >> >> Otherwise the javadoc looks good to me. >> >> -Alan. >
