Re: [commons-logging] Problem renaming logfiles

[Simon Kitching <sk...@apache.org>]

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
> www.sys-internals.com 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
   LogFactory.release(Thread.currentThread().getContextClassLoader());
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 
container!

Some more info on commons-logging can be found here:
   http://wiki.apache.org/jakarta-commons/Logging

Regards,

Simon

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org

Re: [commons-logging] Problem renaming logfiles

[Jeroen Verhagen <je...@gmail.com>]

Hi Simon,

On Apr 1, 2005 3:12 PM, Simon Kitching <sk...@apache.org> wrote:
>
> In general, I would recommend
>    LogFactory.release(Thread.currentThread().getContextClassLoader());
> 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..

calling LogFactory.release(Thread.currentThread().getContextClassLoader());
did indeed not solve the problem...

> 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
> container!

however, calling LogManager.shutdown() did! The multiple handles to
the same logfiles are gone.

Many thanks and regards,

Jeroen

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org