RFR 8159245: Loggers created by system classes are not initialized correctly when configured programmatically from application code.

[Hamlin Li]

Hi Daniel,

Thank you for detailed explanation, new version makes sense to me.
Just another minor comment, I'm not sure if following line is necessary 
in Logger.java, as it's already been checked in LogManager.java line 577:

439 if (cfg == other) return cfg;

Thank you
-Hamlin

On 2016/6/21 19:54, Daniel Fuchs wrote:
> Hi Hamlin,
>
> I was mistaken in my first assessment.
>
> The case where the system handler's list is not empty
> should only happen if by misfortune two different threads
> happen to attempt to merge the same two configurations
> concurrently. Though of no consequence for level, filter,
> etc... (single values) that would be an issue for the
> handlers list if not handled correctly.
>
> With that in mind I have slightly revised the fix - and
> added a more verbose comment explaining the reason for the
> isEmpty() check.
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8159245/webrev.01/index.html
>
> best regards,
>
> -- daniel
>
>
> On 21/06/16 07:57, Daniel Fuchs wrote:
>> Hi Hamlin,
>>
>> There's no difference in behaviour - mergeConfigWithSystemPeer is called
>> unconditionally but the handlers from the application logger will be
>> copied in the system logger config only if the system's logger
>> list is empty - just like before.
>>
>> This is something that will probably need to be revisited - maybe
>> the system handlers should be closed first and the application
>> handlers added unconditionally.
>> The issue here is that if the system logger had handlers
>> configured from the logging.properties file then the user handlers
>> are going to be garbage collected before being closed - which is
>> not ideal - even if it should rarely happen.
>>
>> Let me think on it.
>>
>