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

Daniel Fuchs daniel.fuchs at oracle.com
Wed Sep 10 14:41:15 UTC 2014


On 9/10/14 4:28 PM, Jason Mehrens wrote:
> Daniel
>
>
> I think you should be able to remove the 'other instanceof ConfigurationListener' branch in the ConfigurationListener.equals method.  Should work the same with or without that branch.

Oh yes. I put it there just to avoid it being flagged by
NetBeans:
   'equals() method not checking type of its parameters'
I guess it would be better to just return this == other;
(which unfortunately doesn't remove the warning)
but at least the intent would be clear.

Thanks Jason!

-- daniel

>
>
>
> Jason
>
>
>
> ----------------------------------------
>> Date: Wed, 10 Sep 2014 11:49:51 +0200
>> From: daniel.fuchs at oracle.com
>> To: core-libs-dev at openjdk.java.net
>> Subject: RFR: 8043306 - Provide a replacement for the API that allowed to listen for LogManager configuration changes
>>
>> 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/
>>
>> JDK-8029805 Removed LogManager addPropertyChangeListener
>> and removePropertyChangeListener methods which were
>> deprecated. These methods were deprecated in Java SE 8 and
>> flagged for removal because they were problematic for
>> modularity efforts.
>> The idea was that an application needing to be informed of
>> configuration changes could subclass LogManager and override
>> readConfiguration.
>>
>> The proposed patch adds to new methods to LogManager:
>>
>> public void
>> LogManager.addConfigurationListener(LogManager.ConfigurationListener
>> listener);
>> public void
>> LogManager.removeConfigurationListener(LogManager.ConfigurationListener
>> listener);
>>
>> These methods can be used by those applications for which subclassing
>> LogManager would be too impractical.
>>
>> best regards,
>>
>> -- daniel 		 	   		




More information about the core-libs-dev mailing list