logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen <glenl...@model3.net>
Subject Re: contribs and how does it work
Date Fri, 06 May 2005 13:39:58 GMT

The main use case for HouseKeepingFileAppender is to have the logs there 
if needed but if not needed for the code to keep it's house clean over 
long periods of time.  As I said before these are photo kiosks and they 
can go months without anyone touching them so we don't want to fill up 
the disk with logs but we do get some strange errors from time to time 
and like to keep debug/trace logging on most of the time.

Here are the details (sorry about the fuzzy line between use case and 
technical details, just getting my head around the distinction between 
use case and technical detail)...

- Have the most recent logs be in a directory by themselves so that a 
support person can easily find them.  This could be the last X number of 
  (logs|days|megabytes).  If longer than this move it to the 
"purgatory/archive" directory.

- Have a "purgatory/archive" directory to keep logs longer.  If > X 
number of (logs|days|megabytes) purge the log file.

- The purge/move process is triggered anytime a new log file is created.

- Automatically remove any closed log file that is zero bytes in size

- The (creation) timestamp needs to be embedded in the filename since 
there are scenarios where a file will lose it's file attributes.  Since 
we roll daily this also allows a log file to contain just times (no 
dates) which removes a little bit of noise.  This timestamp is used in 
all the previously mentioned processes to determine a log files age.




Curt Arnold wrote:
> On a similar note, HouseKeepingFileAppender might be better done as a 
> RollingPolicy for the log4j 1.3 RollingFileAppender framework.
> 
> I wouldn't discourage your from filing bugs with the use-cases that you 
> were trying to support.  At least that would allow us to know what 
> concerns prompted the development.  If there are code fragments that you 
> think would fit within a RollingPolicy or TriggeringEventEvaluator, you 
> could copy them into the body of the message.  I think it is unlikely 
> that we'd take the whole appender (at least not into the main stream 
> development), but you could either attach it now or we could come back 
> to you if it looked like it would be helpful.  Attaching the file to the 
> bug would allow others to retrieve the code even if it doesn't make it 
> into a release.
> 
> If you are considering contributing code, you should read 
> http://www.apache.org/licenses/, particularly the section on Contributor 
> License Agreements.  CLA's are required for substantial code 
> contributions to be accepted.
> 
> 
> 
> On May 5, 2005, at 12:31 PM, Scott Deboy wrote:
> 
>> I'd suggest not contributing a new SMTPAppender, but contributing an 
>> implementation of TriggeringEventEvaluator that meets your 'don't send 
>> for 5 minutes' policy.
>>
>> Scott
>>
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org


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


Mime
View raw message