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
