So you are preventing events from getting into the logging hierarchy. Not a bad idea. Why did you not use an IFilter in an appender? It can be modified at runtime using the methods AddFilter() and ClearFilters().
Cheers Von: Howe, Peter L [mailto:ph...@paychex.com] Gesendet: Donnerstag, 6. Juni 2013 21:23 An: Log4NET Dev Betreff: RE: Is<level>Enabled I probably did not explain my question adequately / clearly. What we really need (and have implemented in a wrapper class) is an "inhibit" flag, that turns OFF a particular logging level. I realize it would not be possible or feasible to turn a logging level ON when it has not been configured at application start-up, so what we did in the wrapper class was to have a set of "inhibit<level>" flag properties we could get/set while the application is running, but are only used to (situationally) turn off levels that are not needed.all levels are turned on and configured in the .config file, then some are "inhibited" until they are needed (e.g., WrappedLogger.InhibitDebug = true) and each logging method (Info, Debug, Warn, etc.) looks at the appropriate flag and skips the call to the log4net object if inhibited. Thanks, Peter From: Walden H. Leverich [ <mailto:wald...@techsoftinc.com> mailto:wald...@techsoftinc.com] Sent: Tuesday, June 04, 2013 4:44 PM To: Log4NET Dev Subject: RE: Is<level>Enabled Peter, because of the hierarchical nature of the loggers in log4net I'm not sure turning then on and off that way would be wise. Imagine this logger hierarchy: A A.B A.B.C A.B.C.D I set a logger for A to enable info logging. I set a logger for A.B.C to warn logging. If I check IsInfoEnabled on the A.B logger it will be true, right? Inherited from A If I check IsInfoEnabled on A.B.C.D is will be false, right? Inherited from A.B.C But if I was able to set IsInfo = true on A.B.C.D what does that mean? Is there now a new logger at A.B.C.D? If so, what appenders? If not, do I update the A.B.C logger since that's the first one I find up my tree? The variations and consequences are too crazy to have a correct answer to that question, thus. readonly. :-) IIRC, there is a separate set of method calls for manipulating the logging hierarchy. -Walden -- Walden H Leverich III Tech Software & BEC - IRBManager (516) 627-3800 x3051 <mailto:wald...@techsoftinc.com> wald...@techsoftinc.com <http://www.techsoftinc.com/> http://www.TechSoftInc.com <http://www.irbmanager.com/> http://www.IRBManager.com Quiquid latine dictum sit altum viditur. (Whatever is said in Latin seems profound.) From: Howe, Peter L [ <mailto:ph...@paychex.com> mailto:ph...@paychex.com] Sent: Tuesday, June 04, 2013 11:23 AM To: <mailto:log4net-dev@logging.apache.org> log4net-dev@logging.apache.org Subject: Is<level>Enabled Question: Why are the ILog instance properties (IsDebugEnabled, IsInfoEnabled, etc.) read-only? Would it not be simpler to be able to turn these on or off at will from code, instead of deploying a new XML file? Is there a programmatic way to turn levels on or off (for instance, by an application that reads such switches from a database.)? Thanks in advance. The information contained in this message may be privileged, confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify your representative immediately and delete this message from your computer. Thank you.
