Bug 44557 - no close call to Appender after replacing the root logger
Summary: no close call to Appender after replacing the root logger
Alias: None
Product: Log4j - Now in Jira
Classification: Unclassified
Component: Other (show other bugs)
Version: 1.2
Hardware: PC Windows XP
: P3 normal
Target Milestone: ---
Assignee: log4j-dev
Depends on:
Reported: 2008-03-07 06:01 UTC by Mirko Jahn
Modified: 2008-08-02 15:10 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
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);

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())){

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?