logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: How to roll the file based on size and time?
Date Sat, 20 Feb 2010 05:07:31 GMT

On Feb 19, 2010, at 9:07 AM, Bruno Melloni wrote:

> I know I'll again be writing a unified DailyRollingFile/RollingFile appender for my current
job in the future.  
> Is there any chance to get it included into the main distribution if I contribute it?
 If yes, what standards would it have to adhere to?
> I would rather contribute it than keep rewriting it every time I change jobs.  And my
current company is probably the first that I'm working at that would not object to me contributing
a piece of code like this one even though it would be built on their clock.
> b.

Thanks for the interest to contribute to the project.  There are a lot of issues that could
overwhelm if I threw them all at you.  Be happy to guide you through the issues at the proper

However, as you describe it, my first concern is that you would have the ability to make a
grant of the software to the ASF.  Many times the employer retains rights to all code developed
by their employees in the course of performing their duties.  You'd need to look at the icla
at http://www.apache.org/legal to see if you can agree to its terms.

The second concern is that the software be developed in community.  We are much more likely
to accept software that was discussed on the list prior to the start of coding.  The ASF is
about software developed in an open collaborative manner.  It can digest code developed outside
of a community and has a whole project, the ASF incubator, to bring such code into the ASF,
but it takes a lot of effort to make sure that every i is dotted and t is crossed.

First, have you checked out Simon Park's the time and size rolling appender at http://www.simonsite.org.uk/?

The current RFA in the log4j suite of RFA's run two serious risks:

1) They rename files, an action which is significantly different between Windows (open file
blocks rename) and Unix (rename proceeds and user of open file has no clue).  Also, short
of new features in JDK 7, rename failures give no indication why they failed.

2) They close the old file before opening the new file.  You can be stuck in a state where
you may not be able to open the new file or reopen the old file (say if permissions were changed).

It has been on my wish list for a long time to have an alternative to the current suite of
RFA's based off the framework of MultiFileAppender that has been dormant in the sandbox for
a while.  Since MFA inherently supported having multiple files open at the same time, it should
not be difficult for it to keep the old file open until the new file is acquired.

http://issues.apache.org/bugzilla/show_bug.cgi?id=45165 also search the archives for MultiFileAppender
for some previous discussion.

If you were to build something that actually rolled, I would recommend that you build off
the org.apache.log4j.rolling.RollingFileAppender.  It was the "new" RFA in the abandoned log4j
1.3 development, not backported to log4j 1.2 and packaged in the extras companion (http://logging.apache.org/log4j/companions/extras).
 If is a common RFA with policies that identify when to trigger the rollover and how to rename
and/or compress the files.

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

View raw message