Niclas, I find the idea of filter groups to be intriguing. As for configuration, setting the set of filters for a first level filter group would be fairly easy, but setting groups inside of groups would be impossible with the current DOMConfigurator. Maybe doable with the DigesterConfigurator Ceki has been proposing.
Hm. thanks, -Mark > -----Original Message----- > From: Niclas Hedhman [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, May 28, 2002 7:01 PM > To: Log4J Developers List > Subject: Re: More Filter Thoughts > > > > I have been implementing AND / OR functionality in various > scenarios before > and I think the easiest way is to create a GROUP class that > is a subclass of > or implements (sorry hasn't looked at it yet) the Filter (in > this case). > It basically goes like this; > > public interface Filter > { > boolean evaluate(); > } > > public class FilterGroup > implements Filter > { > private FilterOperator m_Operator; > private Filter[] m_Members; > > public FilterOperator getOperator() > { > return m_Operator; > } > > public void setOperator( FilterOperator op ) > { > m_Operator = op; > } > > public Filter[] getMembers() > { > return m_Members; > } > > public void setMembers( Filter[] members ) > { > m_Members = members; > } > > public boolean evaluate() > { > m_Operator.evaluate( m_Members ); > } > } > public interface FilterOperator > { > boolean evaluate( Filter[] members ); > } > > public class OperatorOr > implements FilterOperator > { > public boolean evaluate( Filter[] members ) > { > for( int i=0 ; i < members.length ; i++ ) > { > if( members[i].evaluate() ) > return true; > } > return false; > } > } > > public class OperatorAnd > implements FilterOperator > { > public boolean evaluate( Filter[] members ) > { > for( int i=0 ; i < members.length ; i++ ) > { > if( ! members[i].evaluate() ) > return false; > } > return true; > } > } > > And since FilterGroup implements Filter, then you may have > groups in groups > and create any complex expression you want. > > How this is going to be defined in configuration is another > story, and one > that I don't know well. > > Hope this helps. > > Copyright note; Any and all of the above code may be used in > any and all ways > conceivable by readers of this message, EXCEPT the user of > the code above can > NOT claim any exclusive rights to it or impose restriction of > its use by > other parties. > > > Niclas > > On Wednesday 29 May 2002 07:04, Mark Womack wrote: > > 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]> > > > -- > 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]>
