Bug 44557

Summary: no close call to Appender after replacing the root logger
Product: Log4j - Now in Jira Reporter: Mirko Jahn <mirkojahn>
Component: OtherAssignee: log4j-dev <log4j-dev>
Status: NEEDINFO ---    
Severity: normal    
Priority: P3    
Version: 1.2   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   

Description Mirko Jahn 2008-03-07 06:01:44 UTC
In my Scenario I need a custom Logger and RootLogger so I created one accordingly, let's call it CustomLogger and RootCustomLogger. Now, when I try to use my newly created logger in the following way:

Hierarchy h = new Hierarchy(new RootCustomLogger((Level)Level.DEBUG));
LogManager.setRepositorySelector(new DefaultRepositorySelector(h), null);
DOMConfigurator.configure(someURL);

I noticed that the default RootLogger is first loaded and configured in the static  initialization block. However, when the new DefaultRepositorySelector is set in the LogManager.setRepositorySelector method, no clean-up of the old RootLogger, contained in the former DefaultRepositorySelector is done. 

This can cause a problem if any of the configured Appenders is still holding resources like file handles (the RollingFileAppender is a good example for that).

In my case, I just inserted the following statement in the LogManager.setRepositorySelector method, before the new RepositorySelector is assigned to the repositorySelector field in the last line of the method:

// if the root logger didn't change, no reason to do that, I guess.       if(!selector.getLoggerRepository().getRootLogger().equals(LogManager.getRootLogger())){
   LogManager.getRootLogger().removeAllAppenders();
}

Not sure, if there are any further clean ups necessary, but for me it does the trick.
Comment 1 Thorbjørn Ravn Andersen 2008-08-02 15:10:42 UTC
Could you elaborate on why you want a custom root logger?