Extending Logger
The complete Log4J manual discourages us from extending Logger but we use the
recommended pattern
then 'repository' and 'getEffectiveLevel()' are inaccessible because they
are protected in Category.
public void trace(Object message) {
if (repository.isDisabled(Level.TRACE_INT)) {
return;
}
if (Level.TRACE.isGreaterOrEqual(this.getEffectiveLevel())) {
forcedLog(FQCN, Level.TRACE, message, null);
}
}
Can we extend Logger ?
--
View this message in context:
http://old.nabble.com/Extending-Logger-tp30018462p30018462.html
Sent from the Log4j - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
RE: [SCL-4] Is it possible to configure different log levels for the same appender based on what logger it is coming from?
One possibility I see: Write an own Filter which is attached to the root logger's Apender and filter out the messages which you do not want. Heri -Original Message- From: Adam Creeger [mailto:adamcree...@gmail.com] Sent: Wednesday, October 20, 2010 11:23 PM To: log4j-user@logging.apache.org Subject: [SCL-4] Is it possible to configure different log levels for the same appender based on what logger it is coming from? Hello all, I have a question regarding how I might configure Log4J to support the following scenario: The root logger has an appender (let's call this Appender Z) with a threshold of INFO. There is some important info messages that get logged to that root logger, so we can't set the threshold any higher... Logger A has some verbose info logging that we wish to log to a separate appender (Appender Y). We want Logger A's warn and error messages to appear in the root logger, but not Logger A's info messages. It is totally fine for Logger A's warn and error messages to appear in Appender Y. If I set additivity to false on Logger A, none of its warn or error messages will make it to Appender Z. If I leave additivity as true, all of its info messages will appear in Appender Z, which is not what we want. Is there something I'm missing here? Thanks! Adam - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
Extending extra RollingFileAppender
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? ___ This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unless specifically indicated, this e-mail is not an offer to buy or sell or a solicitation to buy or sell any securities, investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Barclays. Any views or opinions presented are solely those of the author and do not necessarily represent those of Barclays. This e-mail is subject to terms available at the following link: www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the foregoing. Barclays Capital is the investment banking division of Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may relate to or be sent from other members of the Barclays Group. ___
Re: Extending extra RollingFileAppender
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 it. 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@barclayscapital.com kenneth@barclayscapital.com wrote: 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-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
