Thank you very much for your response Ron.
Funny that you should mention the multi-appender idea. I've already gone
down that road. I rolled my own appender class that mimics appender-ref
functionality of Ansynchronous appender, but leaves out the rest. I've
tested the appender, and it works just like you would think.
The resulting configuration is llike you said:
<appender name="MULTI_ROOT"
class="com.XXXXXXXXX.log4j.appender.MultiAppender">
<appender-ref ref="DEFAULTFILE"/>
<appender-ref ref="CONSOLE"/>
<appender-ref ref="SMTP_ERROR"/>
</appender>
<logger name="com.xyz.dostuff" additivity="false">
<appender-ref ref="MULTI_ROOT"/>
</logger>
<root>
<appender-ref ref="MULTI_ROOT"/>
</root>
On the surface the solution looks good. However, let's say I want to add
another appender for all classes in com.xyz
<logger name="com.xyz" additivity="true">
<appender-ref ref="XYZFILE"/>
</logger>
Since additivity="false" for com.xyz.dostuff, if I want the output from
com.xyz.dostuff to go to XYZFILE appender as well, now I need to add the
appender to both loggers:
<logger name="com.xyz.dostuff" additivity="false">
<appender-ref ref="MULTI_ROOT"/>
<appender-ref ref="XYZFILE"/>
</logger>
Not only am I duplicating appender references, but now I have the same
problem as originally - I have to filter both the XYZFILE appender and the
MULTI_ROOT appender. Instead of just filtering log messages once, I have to
filter them twice, once for each filter. Furthermore, instead of simply
filtering logging events from the com.xyz.dostuff package, now I am
filtering all logging events from all com.xyz.* packages.
Gallagher, Ron wrote:
>
> Appenders can be nested. Simply attach an appender "A" to the logger
> for "com.xyz.dostuff". The configure appender "A" with the filter
> you've described and three nested appenders, one each for the file,
> console and email.
> ...
> The configuration above utilizes the AsyncAppender class which is the
> only class I found in the core log4j libraries that implements both the
> Appender and AppenderAttachable interfaces. If you don't want to
> utilize the asynchronous aspects of this appender, you'll either have to
> roll your own non-asynchronous appender or search the various
> contributions to see if someone has already developed one.
>
> Ron Gallagher
> Cingular Wireless
>
>
> -----Original Message-----
> From: Brett Birschbach [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 23, 2007 5:07 PM
> To: [email protected]
> Subject: Logger (not Appender) Filter
>
>
> 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#a8
> 550568
> Sent from the Log4j - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/Logger-%28not-Appender%29-Filter-tf3077715.html#a8563114
Sent from the Log4j - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
