commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject Re: [commons-logging] Problem renaming logfiles
Date Fri, 01 Apr 2005 13:12:16 GMT
Hi Jeroen,

Jeroen Verhagen wrote:
> I using commons-logging with log4j in my webapp. I'm using a
> DailyRollingFileAppender and every morning when I start developping I
> get the following message in my Tomcat console:
> log4j:ERROR Failed to rename [logfile.txt] to ...
> I did some investigation using the handle utility from
> and found that after a redeploy of my webapp,
> Tomcat is keeping open multiple handles to the same logfile probably
> causing the rename problem. If I restart Tomcat it has only one handle
> to logfile as expected until I redeploy again etc.
> Can someone please tell me what's causing this?
> I'm using Tomcat 5.0.19 with commons-logging 1.0.3 in its common/lib
> dir to also use commons-logging for Tomcat. In every class I declare a
> Log like this:
> private static Log logger = LogFactory.getLog(MyClass.class);
> I tried calling LogFactory.releaseAll() from the webapps
> ContextListener.contextDestroyed() and giving the webapp its own
> commons-logging.jar but that didn't help.
> Thanks for any help and regards,

I expect that you need to ensure that the *log4j* cleanup method
is called when the webapp is undeployed. Calling the *commons logging*
cleanup method is a good idea, but this doesn´t cause
log4j to clean up (in this case, close the log file).

In general, I would recommend
be called on contextDestroyed in order to clean up commons-logging
resources for a specific webapp. In the case of Tomcat, however, the
call to release is done for you by the container so this is not
necessary. Other containers might not be so helpful..

Note that calling releaseAll can release logging resources for *all
webapps in the container* if commons-logging.jar is in a "shared"
classloader (as is the case by default for tomcat).

What the correct log4j cleanup method is depends on how you have 
installed/configured log4j. If log4j is in the WEB-INF/lib directory, 
then I think LogManager.shutdown() is the correct thing to call. If 
log4j is in a shared classloader, however, then you will need to consult 
the log4j documentation in order to figure out how to shut down logging 
for just the webapp being undeployed rather than every webapp in the 

Some more info on commons-logging can be found here:



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message