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

[Daniel Fuchs]

On 21/06/16 16:12, Mandy Chung wrote:
>
>> On Jun 21, 2016, at 4:54 AM, Daniel Fuchs <daniel.fuchs at oracle.com> 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
>
> A related one, what if setLevel is called on a logger while its config is not set to the system logger’s config but system logger’s config is already set with the level previously set?
>
> Would it be simpler if ConfigurationData defines the getter/setter methods and synchronized if it’s being merged?

I don't understand this scenario.
ConfigurationData should remain as simple as possible.
Logger.getLogger() / LogManager.demandSystemLogger() will never return
a logger before it has been configured.
When we're merging the configuration data the system logger has
not been configured yet. Level etc are already volatile in Logger and
we should not introduce any new synchronization there.

best regards,

-- daniel

>
> Mandy
>