RFR: 8043306 - Provide a replacement for the API that allowed to listen for LogManager configuration changes
daniel.fuchs at oracle.com
Wed Sep 10 11:42:20 UTC 2014
On 9/10/14 1:25 PM, Alan Bateman wrote:
> On 10/09/2014 10:49, Daniel Fuchs wrote:
>> Please find below a proposed patch for
>> 8043306 - Provide a replacement for the API that allowed to listen
>> for LogManager configuration changes
>> Proposed Patch:
> It would be nice if ConfigurationListener could be an interface. I
> realize this might mean looking again at the security concerns in this
> area again to see if we could get away without requiring a construction
> time permission check. Clearly if it could be an interface then it begs
> the question as to why it's just not a Runnable but that probably means
> yet more effort to figure out the right security and whether the access
> control context should be recorded when registering.
One nice thing about ConfigurationListener being an abstract class is
that I don't need to invent an 'IdentityCopyOnWriteArrayList' which
is what I would prefer to use if equals() could be overriden by
Also I like it that you need to have the LoggingPermission("Control")
to subclass ConfigurationListener.
In practice - I believe that there aren't that many application
which need this functionality - and I also believe that for those
that need it then there will be a single ConfigurationListener
that will be registered only once, and therefore having an
abstract class for ConfigurationListener shouldn't be that much of
a hassle for them.
> Assuming ConfigurationListener remains as an abstract class then the
> no-arg constructor will need a one-line javadoc comment.
Oh - right - thanks for catching that.
> A small suggestion for addConfigurationListener to return LogManager to
> facilitate method invocation chaining when configuring the LogManager.
> It could be done for remove too but that is probably less interesting.
> Another comment on addConfigurationListener is that about the wording
> "re-read and the configuration is changed". I think the configuration
> listeners are invoked when ever the configuration is read even if there
> aren't any changes.
Right. Although I believe it would be difficult (though maybe not
impossible) to manage to register a configuration listener before
the configuration is read for the first time ;-)
> The javadoc links in the readConfiguration methods make the line length
> a bit inconsistent with the existing javadoc, maybe the package name
> could be just dropped from the links or the link moved to the next line.
OK - I'll see what I can do.
More information about the core-libs-dev