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: Extending extra RollingFileAppender
Date Fri, 22 Oct 2010 01:16:24 GMT
The motivation for making the class final is that it was designed to be extended via the TriggeringPolicy
and RollingPolicy classes.  Joshua Bloch's design pattern of design for inheritance or prevent

If you can accomplish your goal by providing a custom TriggeringPolicy or RollingPolicy that
would be the best approach.  If you still run into a wall, you could describe how you would
like to modify the class and  providing a mechanism (either through the existing strategy
classes or via a new one) to support that modification could be considered.

If not, then consider encapsulating the class (a bother since the Appender method has so many
methods).  If that isn't viable, then copy and pasting the appender source and changing the
package, class name or both (while staying within the Apache Software License) is better than
tweaked version of log4j with the final qualifier removed.

On Oct 21, 2010, at 4:17 PM, <Kenneth.Lam@barclayscapital.com> <Kenneth.Lam@barclayscapital.com>

> Hi,
> I am looking to modify a small part of the write behavior for org.apache.log4j.rolling.RollingFileAppender
from the extra companion jar.  However, the class is declared as final.  Is there any particular
reason why this was done?  Would removing the final keyword and extending the class my self
be dangerous?

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

View raw message