Mailing-List: contact log4j-dev-help@logging.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Log4J Developers List" <log4j-dev@logging.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Date: Thu, 27 May 2010 19:54:33 +0200 (CEST)
From: "Ersek, Laszlo" <lacos@caesar.elte.hu>
To: log4j-dev@logging.apache.org
Subject: docs bug? "rolling.RollingFileAppender" has no "MaxBackupIndex"
Message-ID: <Pine.LNX.4.64.1005271927060.16294@login01.caesar.elte.hu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

Hi,

I'm trying to create a log4j config where rotation is triggered by file 
size, an rotation includes compression. Browsing the docs and the config 
DTD, my purpose seems achievable with rolling.RollingFileAppender + 
SizeBasedTriggeringPolicy + TimeBasedRollingPolicy. (The latter is only 
needed because it seems to be the only rolling policy that supports 
compression out of the box.)

Hence I created a config file for the DOM configurator. In fact, I'm 
converting an older config file which was written for the property 
configurator. The old configuration used the original (not extras) 
RollingFileAppender. I'm having trouble converting the MaxBackupIndex 
property of that older class. Any MaxBackupIndex seem to make no sense for 
the new rolling.RollingFileAppender, since that one requires an explicit 
rolling policy.

My problem is that the API docs do talk about MaxBackupIndex, in the 
description of rollover():

http://logging.apache.org/log4j/companions/extras/apidocs/org/apache/log4j/rolling/RollingFileAppender.html

I downloaded apache-log4j-extras-1.0.tar.gz and tried to look at the code 
(src/main/java/org/apache/log4j/rolling/RollingFileAppender.java). It 
appears to me that the class has indeed no business with any 
MaxBackupIndex -- the only mentions are in the leading comment of 
rollover() (which is probably the source of the javadoc occurrences too).

I checked the bugzilla with "Product: Log4j, Summary: maxbackupindex", and 
it only returned #24407, which is irrelevant here ("large maxbackupindex 
makes RollingFileAppender dread slow").

So is this a documentation bug?

... Furthermore, now that I'm looking at the source of 
FixedWindowRollingPolicy, it does seem to support gzip compression. Its 
description doesn't mention it though (while that of its sibling class 
TimeBasedRollingPolicy does):

http://logging.apache.org/log4j/companions/extras/apidocs/org/apache/log4j/rolling/TimeBasedRollingPolicy.html
http://logging.apache.org/log4j/companions/extras/apidocs/org/apache/log4j/rolling/FixedWindowRollingPolicy.html

so I think people are led to believe that only TimeBasedRollingPolicy 
supports compression. Is this another documentation bug?


In closing, thank you very much for this great software!

Cheers,
lacos

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