Log4J problem

[FET]

Hi everyone,

Consider the following piece of code:

Logger mylogger = Logger.getLogger(Log4JFileDeletionTest.class);

public Log4JFileDeletionTest() throws Exception
{
FileAppender fapp = new FileAppender(new
XMLLayout(),"/tmp/Log4JFileDeletionTest.log",true);
mylogger.setLevel(Level.DEBUG);
mylogger.addAppender(fapp);

mylogger.info("This is a test log");

Thread.sleep(7000);


mylogger.info("This is after deleting the file");
}

If during the Sleep(), I delete the log file, then none of the
subsequent log statements re-create the file. It remains deleted, no
exceptions get thrown and all the logs are lost.

Is there any solution to this, other than modifying the log4J code ?

Thanks in advance.

 

[Phillip Mills]

Is there any solution to this, other than modifying the log4J code ?

How about either subclassing or wrapping Logger with a class of your own
and having yourlogger.info() do whatever you want?

 

[Marcus Eaton]

If during the Sleep(), I delete the log file, then none of the
subsequent log statements re-create the file. It remains deleted, no
exceptions get thrown and all the logs are lost.

Is there any solution to this, other than modifying the log4J code ?

I tried to run your test (on a windows machine), but was unable to
delete the file. Anyhow, looking at the log4j code, the file output
stream is created when you initialise the appender... therefore, i don't
think it would implicitly try to re-create it per info/debug message.

How about either subclassing or wrapping Logger with a class of your
own and having yourlogger.info() do whatever you want?

Sublassing the Logger will not do it, but you could create a sub-class
of the FileAppender, which re-initialises the stream/file per event, but
that creates too much over-head.

It might be a silly question, but why do you need this functionality
anyway? Do you expect your users to constantly be deleting your log
files?

Marcus

 

[Manfred Rosenboom]

On a Unix like system the file will be deleted in the directory entry, but
the file's entries in the file system will be still allocated until you close
the last file descriptor to this file. I.e.: Log4j will still write to the
file but you can neither see nor access the file anymore.

Why you don't use a rolling file appender wiht Log4j ?

Best,
Manfred

 

[FET]

Even in a RollingFileAppender, if the first file is deleted,
everything held in the buffer is lost when the max size is reached. It
is only when the new buffer is created, that a new file gets created.

Anyway, actually the reason for posting this problem is that I was
thinking about all possible test cases for the application and this is
also a possibility, though remote.

Thanks a lot all you guys for your prompt response!