FULL PRODUCT VERSION :
java version "1.7.0_40"
Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
Java HotSpot(TM) Client VM (build 24.0-b56, mixed mode, sharing)

java version "1.7.0_40"
Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601]
  and
Microsoft Windows XP [Version 5.1.2600]


A DESCRIPTION OF THE PROBLEM :
Using some library seems to change the logger context 'spontaneously'. It looks like it is caused by an invocation of AppContext.getAppContext() which will, sometimes, change the logger context from there on.

What seems to happen:
- getUserContext() in LogManager returns userContext as long as there is no SecurityManager and no JavaAWTAccess.
- As soon as both a SecurityManager and JavaAWTAccess are available, it decides (once) if it should add userContext to javaAwtAccess or a new LoggerContext.
- If that decision is caused by invocation of AppContext.getAppContext(),
             'javaAwtAccess.isMainAppContext()'
in LogManager.getUserContext() returns false if PLatformLogger was already redirected in LogManager
         sun.util.logging.PlatformLogger.redirectPlatformLoggers()

Of course this easy to prevent in the sample code, but since various invocations are done by libraries, we have no control if our logger context changes.

Some examples of code invoking AppContext.getAppContext();:
- IIORegistry.getInstance()
- getRegistry(...) in java.rmi.Naming.list()
- new java.swing.ImageIcon.ImageIcon(...)
and more....


REGRESSION. Last worked in version 7u21

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run sample code and you will get two different instances for the logger.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Same instance of the logger
ACTUAL -
Different instance after getAppContext() because of new LoggerContext

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
package Bugs;

import java.util.logging.Logger;
import sun.awt.AppContext;

/*
 * VM arguments
 * -Djava.security.manager -Djava.security.policy=file:/c:/somewhere/all.policy
 * ----------------------
 * all.policy
 * ----------------------
 * grant {
 * permission java.security.AllPermission;
 * };
 * ----------------------
 *
 * Application arguments
 * - None, results in two different loggers (for update 25 and 40).
 * - Any, all loggers in userContext.
 */

public class LoggerContextWrong {

  private static final String ONE = "LoggerOne";

  public static void main(String[] args) {
    if (args.length > 0) {
      System.out.println("all same userContext");
      AppContext.getAppContext();
    }
    else {
      System.out.println("separate Logger context");
    }

    if (System.getSecurityManager() == null) {
      System.setSecurityManager(new SecurityManager());
    }
    Logger a1 = Logger.getLogger(ONE);

    AppContext.getAppContext();

    Logger b1 = Logger.getLogger(ONE);

    System.out.println();
    System.out.println("Before = " + a1);
    System.out.println("After = " + b1);
  }
}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Invoke as early as possible:
AppConetext.getAppContext()
- or -
  Toolkit.getDefaultToolkit()
- or -
 SwingUtilities.invokeLater(new Runnable() ......

These SEEM to prevent the issue.