Scott, Yes, the basic filter functionality provides what you have outlined. My point, and I did not make it clear, is that the filter implementations that ship with log4j in the varia package do not support configuring "AND" filter chains because they are limited by the AcceptOnMatch functionality. On a match they either return Filter.ACCEPT or Filter.DENY and when there is no match they return Filter.NEUTRAL. Except for LevelRangeFilter which confuses the entire thing by returning Filter.ACCEPT or Filter.NEUTRAL on a match. So, if you needed the "AND" filter chain functionality you would end up writing your own filter or modifying the one that ships with log4j.
I have been working on the filters to expand the available set. My thinking is that just like there is a useful set of appenders that ship with log4j, there should be a useful set of filters. I feel that the current filter implementations limit their usefulness and users will end up writing their own anyway. Unless I am missing something. thanks, -Mark > -----Original Message----- > From: Scott Farquhar [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, May 28, 2002 3:36 PM > To: Log4J Developers List > Subject: Re: More Filter Thoughts > > > I'm not well versed on filters - but can't you chain them to get the > "AND" functionality that you require? > > Filter A - if a == true pass to filter B > Filter B - if b == true pass to logger. > > Or is there extra functionality that I am missing? Is it actually > possible to chain filters as in above? > > Scott > > Mark Womack wrote: > > When implementing some filters this weekend I found that > there is a flaw in > > the set of filters that log4j provides in the varia > package, at least in my > > opinion. Primarily, using the AcceptOnMatch property, it > is very easy to > > create a filter chain of "OR" type tests, but very > difficult to create a > > filter chain of "AND" type. At least it looks that way to > me. Maybe this > > isn't a big deal. > > > > By "OR" type filter chain I mean a logging event is either > accepted/denied > > if it matches filter 1 OR filter 2 OR filter 3, etc. If > the event does not > > match the filter criteria, it is passed on to the next filter. > > > > By "AND" type filter chain I mean a logging event is either > accepted/denied > > if it matches filter 1 AND filter 2 AND filter 3, etc. If > the event does > > not match the filter criteria it is denied. When it > matches the filter > > criteria, it is passed to the next filter via > Filter.NEUTRAL. Optionally, > > when an event does not match, you could have the filter > accept the event > > instead of deny it (this allows passthru filters, like > SetLevelInfoFilter, > > to process some event but not others). > > > > The AcceptOnMatch property/concept doesn't handle the AND > case very well. I > > admit that my previous filter submissions were more > complicated than they > > needed to be, but they did allow both OR and AND type > filter chains with > > simple runtime configuration settings. Does anyone else > think this is > > important? Am I missing something or spending too much > time on what is > > essentially a simple matter? > > > > I have come up with an idea of how to extend the current > set of filters to > > allow OR and AND while maintaining backward compatibility, > but I want to > > hear what others think before I propose it. > > > > -Mark > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- Scott Farquhar :: [EMAIL PROTECTED] Atlassian :: http://www.atlassian.com Supporting YOUR J2EE World -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
