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 incident


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 < log4j-dev@logging.apache.org>
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 http://developer.spikesource.com
>  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
> http://www.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.

Yahoo! Answers - Get better answers from someone who knows. Try it now.