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

[Daniel Fuchs]

New webrev:

http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.01

-- daniel

On 9/10/14 1:42 PM, Daniel Fuchs wrote:
> On 9/10/14 1:25 PM, Alan Bateman wrote:
>> On 10/09/2014 10:49, Daniel Fuchs wrote:
>>> Hi,
>>>
>>> Please find below a proposed patch for
>>>
>>> 8043306 - Provide a replacement for the API that allowed to listen
>>>           for LogManager configuration changes
>>> https://bugs.openjdk.java.net/browse/JDK-8043306
>>>
>>> Proposed Patch:
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.00/
>>>
>> 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
> implementations.
>
> 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.
>
> Good suggestion.
>
>> 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.
>
> Thanks Alan!
>
> -- daniel
>
>>
>> -Alan.
>>
>>
>