RFR: 8023168 - Cleanup LogManager class initialization and LogManager/LoggerContext relationship

[Mandy Chung]

On 9/4/2013 12:56 PM, Daniel Fuchs wrote:
> Hi,
>
> Please find below a changeset that will fix
>
> 8023168: Cleanup LogManager class initialization and
>          LogManager/LoggerContext relationship.
>
> <http://cr.openjdk.java.net/~dfuchs/webrev_8023168/webrev.00/>
>

It is good to see the LogManager/Logger initialization untangled. This 
helps in the long run.

LogManager.java L342: thanks to adding the assert here. L340-341 can be 
removed.
This will be helpful in debugging (rather than swallowing the 
exception).  The initialization has been so fragile and swallowing the 
exception makes the problem even worse.  With this cleanup, I think the 
initialization code will be more robust.

The ensureLogManagerInitialized method does the rest of the 
initialization for the global log manager - it reads the configuration, 
instantiates and registers the root logger, and also register the global 
logger.  The comment L289-292 about deadlock between two class 
initializers needs to be revise.

I agree with David that it's worth exploring if lazy holder class idiom 
would help here - perhaps a holder class with a static rootLogger field.

Since you touch these lines, it's good to switch to try-with-resource.

1205         final InputStream in = new FileInputStream(fname);
1206         final BufferedInputStream bin = new BufferedInputStream(in);
1207         try {
1208             readConfiguration(bin);
1209         } finally {
1210             in.close();
1211         }

Logger.java - getGlobal() method: would it help if the holder class
has static Logger global field which is set during its class
initialization.  It should guarantee that global.manager is set
and the log manager initialization completes??

I was wondering if this can be simplified.

thanks
Mandy