On 21/06/16 16:12, Mandy Chung wrote:
On Jun 21, 2016, at 4:54 AM, Daniel Fuchs <daniel.fu...@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
