While I was looking at Logging API deadlock issues, I happened
to notice that the test for the following bug fix is missing:

6487638 3/3 Calling LogManager.addLogger() and Logger.getLogger() cause deadlock

The above fix should have added the following SDK/JDK test:

    java/util/logging/LoggingDeadlock3.java

I dug around my archives and I found the Serviceability integration
message for JDK7-B14:

------------------------------------------------------------------------------
JPRT Job ID: 2007-05-19-001112.ss45998.sdk7
JPRT System Used: sfbay
JPRT Version Used: 16 Apr 2007 - National Eggs Benedict Day
Job URL: http://javaweb.sfbay/jdk/jprt/archive/2007/05/2007-05-19-001112.ss45998.sdk7
User: ss45998
Email: ###@###.###
Release: jdk1.7.0
Job Source: Teamware: /net/tomsk.sfbay/export/home/ss45998/1.5/sdk7/{make,src}
Parent: /java/svc/ws/j2se/service_sdk_baseline
File List: {src/share/classes/java/util/logging/LogManager.java,src/share/classes/java/util/logging/Logger.java,test/java/util/logging/LoggingDeadlock3.java,test/java/util/logging/LoggingDeadlock3.props}
Command Line: jprt submit -w /net/tomsk.sfbay/export/home/ss45998/1.5/sdk7 -p /java/svc/ws/j2se/service_sdk_baseline -email ###@###.### -m /home/ss45998/jpdaWork/fix/comment_file.lmd3 -release jdk1.7.0 -cr 6487638 src/share/classes/java/util/logging/LogManager.java src/share/classes/java/util/logging/Logger.java test/java/util/logging/LoggingDeadlock3.java test/java/util/logging/LoggingDeadlock3.props
------------------------------------------------------------------------------

Fixed 6487638: Calling LogManager.addLogger() and Logger.getLogger() cause deadlock [Tim Bell]

Webrev:
     http://javaweb.sfbay/~ss45998/webrev/2007/lmd3.May10

Problem:
  This is another deadlock issue in the logging API
  which was in the implementation from the beginning.
  The following two public methods can be called from different threads concurrently:
    - synchronized instance method LogManager.addLogger()
    - synchronized static method Logger.getLogger()

  The following deadlocking scenario is possible:
  T1:
    Locks the LogManager object, calls LogManager.addLogger() which calls
    Logger.getLogger() which is waiting to lock the Logger Class object.

  T2:
    Locks the Logger Class object, calls Logger.getLogger() which calls
    LogManager.getLogger() which is waiting to lock the LogManager object.

Solution:
    The fix is to remove this bad cyclic dependency between the
    LogManager and Logger classes.

Approved by: No approval is needed

Reviewed by:
  Tim Bell

Fix verified (y/n): y
  New regression test:
    java/util/logging/LoggingDeadlock3.java

Verification testing:
  All the java.util.logging nsk, jtreg and jck tests.

Other testing:
  JPRT


------------------------------------------------------------------------------

Files:
update: src/share/classes/java/util/logging/LogManager.java
update: src/share/classes/java/util/logging/Logger.java

Examined files: 2

Contents Summary:
       2 update


The teamware command log shows that:

    test/java/util/logging/LoggingDeadlock3.java
    test/java/util/logging/LoggingDeadlock3.props

were both named on the command line, but the "Files:"
part of the log does not show "create:" entries for
those two files. I'm going to guess that Serguei forgot
to do an "sccs create" on the files.

I found both files in the webrev attached to 6487638,
removed all the HTML stuff, and I'm attaching the files
to this bug.