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?