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

[Daniel Fuchs]

On 21/06/16 04:29, Hamlin Li wrote:
> Hi Daniel,
>
> I just has one simple question.
> In new version, in Logger::importConfig, userParentHandlers, filter,
> levelObject are copied from other(ConfigurationData) unconditionally,
> handlers in other are only *copied *when it's empty in system.
> In previous version, handlers in other are *added *(which means merge 2
> set of handlers)**unconditionally.
> is this different behavior expected?

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.

best regards,

-- daniel

>
> Thank you
> -Hamlin
>
> On 2016/6/21 0:34, Daniel Fuchs wrote:
>> Hi,
>>
>> Please find below a patch for:
>>
>> 8159245: Loggers created by system classes are not initialized
>>          correctly when configured programmatically from
>>          application code.
>>
>> Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8150173
>>
>> Patch:
>> http://cr.openjdk.java.net/~dfuchs/webrev_8159245/webrev.00/index.html
>>
>> When an application requests a logger by name, we do not know before
>> hand whether that corresponds to a system logger name or not.
>> So if no system logger by that name already exists, we simply return an
>> application logger.
>>
>> The issue happens if a system class later requests a system logger
>> of the same name. The current implementation would simply copy over
>> the user logger handlers to the system logger, ignoring any other
>> data (level, filter, flags) that might have been set by the application
>> (with permission checks) prior to the creation of the system logger.
>>
>> The proposed patch ensures instead that if a system class later
>> requests a system logger of the same name, then the application logger
>> and system logger configurations will be merged in a single instance of
>> a private static Logger$ConfigurationData value class that both loggers
>> will share.
>>
>> A new test is added to verify that the configuration issue is fixed in
>> the various possible configuration cases:
>>
>>   - parent of system logger created by the application before system
>>     logger exists,
>>   - parent of system logger created by the application after system
>>     logger exists,
>>   - logger created by the application before system logger of the
>>     same name exists
>>   - logger created by the application after system logger of the
>>     same name exists
>>   - all of the above with and without a security manager.
>>
>> The new test will fail without the fix and pass with it.
>>
>> best regards,
>>
>> -- daniel
>