i tought your first idea of having loggers which can be configured to filter the events was quite appealing. however i can't say if this would be a bad design idea for some architectural/performance reason(s). [actually i suspect that there is a reason why this is not done yet, mainly because your proposal sounds too useful to not be implemented ;-)]
you'd have to subclass Logger and do your own LoggerFactory for this as you say and it would be nice if it was configurable in the same way as the appender filters. cheers patrick > -----Ursprüngliche Nachricht----- > Von: Brett Birschbach [mailto:[EMAIL PROTECTED] > Gesendet: Mittwoch, 24. Januar 2007 16:56 > An: [email protected] > Betreff: RE: Logger (not Appender) Filter > > > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
