Is there a good reason why the default log4j implementation does not allow for a filter at the Logger level? I know we can add filters to Appenders, but there are certain scenarios where this can be quite wasteful on resources. Perhaps I am attacking this situation all wrong?
Scenario: -Using code developed by a different company. -The code from package com.xyz.dostuff generates a log.error, including the stack trace, whenever an exception occurs. -If the Exception descends from a certain type of exception, I do not want the exception to clutter up the log with the stack trace, nor be logged at the error level. -The root logger has 3 appenders (file, console, and email) Possible Solution: -Add a filter to all 3 appenders to filter out the undesired log.error's Cons: -Repeatitive declarations (adding filter to all 3 appenders) -Every single log statement that goes through the root logger must go through the filter -For every single log statment, the filter is executed 3 times, once for each filter Proposed Solution: -Add a filter (not possible using default log4j) to the specific logger com.xyz.dostuff Pros: -Only need to add the filter to one logger vs. three appenders -Only log messages from the specific package com.xyz.dostuff must pass through the filter -The filter is executed only once for each log statement. 1) Am I overlooking this functionality, and is it already built into log4j? 2) Am I looking at this problem completely wrong, and is there a better approach? 3) If 1) and 2) are no, are there any drawbacks to me wrapping the org.apache.log4j.Logger class and adding the functionality for filters? I assume I would need to override the default configuration classes as well? -- View this message in context: http://www.nabble.com/Logger-%28not-Appender%29-Filter-tf3077715.html#a8550568 Sent from the Log4j - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]