In the package java.util.logging, an instance of Logger is obtained using the Logger.getLogger() method, the returned instance is held permanently for the life of the JVM by a strong reference inside the log manager. This is causing some problems in the JBI (JSR208) Reference Implementation. One of the API methods we must provide is a method to allow a JBI plug-in component to request a logger. We in turn use the standard Logger implementation to request a logger on behalf of the component and then return that instance to the component. We support an optional resource bundle provided by the component to be used by that logger.
The problem is that during the lifetime of a single execution of JBI, which is a Lifecycle Module running inside the AppServer, a JBI plug-in component could be installed, started, shut down, and uninstalled any number of times. This could be an upgrade of the JBI plug-in component, which could include updates to its resource bundle. However, because the J2SE log manager never releases the Logger instance, when the JBI plug-in component requests a logger when it is being restarted, it still gets the original Logger instance which has the out-of-date resource bundle.
It seems there should be a way to force the log manager to release a Logger instance that is no longer being used so that situations like this would not occur. We've tried forcing a GC run after releasing all of our references to the logger (when the plug-in component is shut down), but this does not help.
Refer to CR #6263011 for more information.
  xxxxx@xxxxx   2005-05-23 23:42:48 GMT

N/A

Yes, the LogManager saves the strong references to the Logger objects
in the loggers hashtable. Please, see the code fragment from LogManager.java
below:
  	// We're adding a new logger.
  	// Note that we are creating a strong reference here that will
  	// keep the Logger in existence indefinitely.
  	loggers.put(name, logger);

This is is against the spec and has to be fixed.
Posted Date : 2006-08-30 18:01:03.0