logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Park <simon_park_m...@yahoo.co.uk>
Subject Re: DailyRollingFileAppender.java enhancement
Date Fri, 25 Jan 2008 08:47:50 GMT
Hi Manish,

The LogFileScavenger class is coded to delete all older files, regardless of extension, that
share the root (or base) name.  I suppose you could say that it's quite ruthless!


----- Original Message ----
From: Manish Marathe <python.ruby@gmail.com>
To: Log4J Developers List <log4j-dev@logging.apache.org>
Sent: Thursday, 24 January, 2008 6:45:18 PM
Subject: Re: DailyRollingFileAppender.java enhancement

On Jan 22, 2008 11:51 PM, Simon Park <simon_park_mail@yahoo.co.uk> wrote:

Hi Manish,

I contributed some code a few months ago that might fit the bill.  It's an appender that behaves
similarly to the DailyRollingFileAppender, yet it also deletes older files.  You can configure
the number of files you wish to keep.  A daemon thread periodically scans the files based
upon the "root" of the filename, 
i.e. it's independent of the pattern.  Code available at http://www.simonsite.org.uk/resources/lib/log4j-rolling-appender.jar
 and Javadoc at http://www.simonsite.org.uk/javadoc/org/apache/log4j/appender/TimeAndSizeRollingAppender.html
.  This code has been running in production on an SMP platform for just under a year, without


That looks cool. Although I didn't go through great detail but just a question. Suppose the
"root" name of my log file is "
net.log". I initially use a date pattern yyyy-MM-dd for some time, giving no.of files to keep
say 10. On the 11th night, just before midnight, I change the pattern to yyyy-ww and restart
tomcat/my-app. Now I have 10 rolled-over log files with date pattern yyyy-MM-dd, since 
no.of files to keep is 10 no files will be deleted. On the 12th night, does TimeAndSizeRollingAppender
deletes the oldest log file which had pattern yyyy-MM-dd or will it not consider those rolled
over log files to delete at all because they are not in accordance with the pattern set in
the configuration file?

If TimeAndSizeRollingAppender is just looking for root file name, in my case "net.log", will
it also delete older rolled-over log files with older pattern?



----- Original Message ----

From: Manish Marathe <python.ruby@gmail.com>
To: Log4J Developers List <
Sent: Monday, 21 January, 2008 12:14:04 AM
Subject: Re: DailyRollingFileAppender.java enhancement

On Jan 20, 2008 2:50 PM, Curt Arnold <carnold@apache.org> wrote:

On Jan 20, 2008, at 3:42 PM, Manish Marathe wrote:

> Hello All,
> Currently the Appender, DailyRollingFileAppender, rolls over the log
> file as per the "datePattern" set in the configuration file,

> although the rolled-over files never get deleted unlike if we use
> RollingFileAppender but in case of RollingFileAppender we cannot use
> the datePattern.
> In one of our products in my company, SpikeSource Inc, I needed a

> feature to delete the rolled over oldest files so I extended
> DailyRollingFIleAppender.java to add SET and GET methods for
> maxBackupIndex, one of the parameters we can set in the
> configuration file, and implemented and the deletion of rolled over

> "oldest".
> I would be happy to give this back to log4j community unless someone
> has already added the feature.
> I am a developer from SpikeSource Inc and I plan to blog about it on 
>  and make it available from there but its better to include in the
> library itself and make it available to the whole community.

> Actually the feature add and implementation is so simple and less of
> a code, if given permission I can actually modify
> DailyRollingFileAppender.java and give it back.
> Hopefully this will be helpful to someone.

> Thanks
> Manish
> SpikeSource, Inc
> http://developer.spikesource.com


It would be interesting to hear your approach.  It has been a
frequently asked enhancement, but the flexibility of using date
patterns made implementing an algorithm to find the

"oldest" (particularly for patterns that omitted significant portions
of the date) difficult to do in a way that would work consistently.

Yes, I actually searched a lot and happen to learn from some of the replies of Log4J developers
explaining the same point that finding an oldest file with respect to the date pattern set
is quite difficult and that too consistently and I agree with that. Also I am sure implementing
what I state below must have been thought earlier and for some good reason discarded.

My approach was simple, may be specific because of specific needs for the product I was working
on and that made the implementation easier. Although here is the simple approach.

In my implementation, I supported, the following date patterns:

1) yyyy-MM-dd
2) yyyy-MM-dd-HH
3) yyyy-MM-dd-a
4) yyyy-MM-dd-HH-mm
5) yyyy-MM
6) yyyy-ww

Looking at the DailyRollingFileAppender, I am afraid the above one's are the basic date patterns
supported by DailyRollingFileAppender and essentially all those that SimpleDatePattern supports.
Using the above date patterns I check for all the rolled over log file names that has the
original filename as its substring and also matches with the pattern ".*[0-9][0-9][0-9][0-9]-[0-1][0-9]-[0-3][0-9].*"
for example if we consider the date pattern set in the configuration file is yyyy-MM-dd, the
default one set in DailyRollingFileAppender as well.

Using .lastModified method of a File object, we can sort a list of all the rolled over log
files we get above and delete the oldest with respect to the maxBackupIndex. 

Now If someone wants to use a date pattern other than mentioned above, one can also added
a  regex pattern for that date-pattern using some parameter in the configuration file. That
can be retrieved in the Appender's code and used to matched with the rolled-over log files.

Lastly if someone wants no rolled over log files to get deleted, one can simply set maxBackupIndex
set to -1.

The best place for such an enhancement would be in "extras" companion (http://logging.apache.org/log4j/companions/extras

) which is a collection of new features and enhancements that can be

used with log4j 1.2.x deployments (back to at least 1.2.9, but may
work back further).   The extras has the
org.apache.log4j.rolling.RollingFileAppender (notice the
extra .rolling. in the package name) framework that was back-ported

from the abandoned log4j 1.3 development.  It would be best to do any
enhancement in that framework instead since it already addresses many
issues with the main-line RFA and DRFA.

Sure thanks Curt, I will do that if this is really useful and that the implementation of the
approach above is not too specific for my needs only.

       Sent from Yahoo! - a smarter inbox.

Support the World Aids Awareness campaign this month with Yahoo! For Good http://uk.promotions.yahoo.com/forgood/
View raw message