Ceki, So, I think we are on the same page here. The RejectOnMismatch property is one way to solve it, and it might be a better way. I don't know. I was going to propose this:
1) Leave the current set of varia filters as they are and possibly deprecate them in a future version. Create a o.a.log4j.filters package and create a new set of base filters that are more powerful and flexible (this does not mean changing the current, underlying filter design...only exposing the existing ternary logic in way that is useful). The current set of varia filter functionality would migrate to the new package, etc. We could work out the new design. OR 2) Leave the current set of varia filters as they are and simply extend their interface to expose more of the filter features. I was going to recommend 2 new methods setMatchReturnVal(Level) and setMismatchReturnVal(Level). The current filters could default to their current match/mismatch values for each return value, AcceptOnMatch would set these 2 values so the filters act like they do today, ensuring backward compatibility. But these 2 new properties could be set via configuration files and expose the useful functionality. Or we could look at adding Mismatch filters with RejectOnMismatch() instead. Whichever works better. Or there might be a third option I have not thought of yet. I don't have a strong opinion of one over the other, as long as the useful functionality is exposed via a larger set of available filters. That is the goal. -Mark > -----Original Message----- > From: Ceki Gülcü [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, May 28, 2002 11:48 PM > To: Log4J Developers List > Subject: RE: More Filter Thoughts > > > > Hi Mark, > > As the previous email notes indicate, there is some confusion > regarding the ternary logic in log4j filters. Log4j filters are based > on the same structure as Linux ipchains (called iptables in Linux > 2.4). The ternary logic allows the *composition* of filters, meaning > that one can assemble various built-in filters together and compose > the overall filtering behavior. Filters are a poorly documented log4j > feature which explains why so few people understand them or use them. > At the same time, there is no doubt in my mind that ternary filters > are the best solution to the "declarative filter composition" > problem. In plain English, this is the problem of composing various > filters together by declaring them in a configuration file. This is > problem is substantially different than coding a complex filter in an > all-purpose language like Java or C. > > > 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. > > Bulls eye, that is indeed the whole point of the exercise. > > > 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. > > You are right. AcceptOnMatch is geared towards "OR" filter chains. For > example, here is a filter chain that will accept any event containing > the message "hello" *or* any event containing the message "world" but > reject everything else: > > <filter class="org.apache.log4j.varia.StringMatchFilter"> > <param name="StringToMatch" value="hello" /> > <param name="AcceptOnMatch" value="true" /> > </filter> > > <filter class="org.apache.log4j.varia.StringMatchFilter"> > <param name="StringToMatch" value="world" /> > <param name="AcceptOnMatch" value="true" /> > </filter> > > <filter class="org.apache.log4j.varia.DenyAllFilter"/> > > If you are unfamiliar with filters, try it. It works. > > As Mark pointed out, a filter chain that would accept only messages > containing both "hello" *and* "world" cannot be expressed with the > existing log4j filters. This is not a limitation of the ternary logic > but the lack of appropriate log4j filters. > > What is missing? Compared to Linux ipchains the missing ingredient is > the NOT operator. AcceptOnMatch is geared towards an action to perform > when there is a match (the action being REJECT or ACCEPT). There is no > way to tell it to ACCEPT or REJECT on a *mismatch*, existing filters > only return NEUTRAL on mismatch. > > Here is an imaginary filter chain that would only let through events > containing the string "hello" and "world" in their message part: > > <filter class="org.apache.log4j.varia.StringMismatchFilter"> > <param name="StringToMatch" value="hello" /> > <param name="RejectOnMismatch" value="true" /> > </filter> > > <filter class="org.apache.log4j.varia.StringMismatchFilter"> > <param name="StringToMatch" value="world" /> > <param name="RejectOnMismatch" value="true" /> > </filter> > > (Note the class of the filters: it's StringMismatchFilter not > StringMatchFilter.) > > This chain rejects any event that does not contain the string > "hello". It also rejects any event that does not contain the string > "world". Note that there is no "DenyAllFilter" at the end of the chain > such that events that pass the two filters are accepted (i.e. logged). > > "RejectOnMismatch" is one possible term, "AcceptOnMismatch" > is another possible term, where specifying > > <param name="RejectOnMismatch" value="true" /> > > is equivalent to specifying > > <param name="AcceptOnMismatch" value="false" /> > > It should be clear that creating a new Mismatch filter for each filter > type is just one possibility. Another approach is to combine the > match/mismatch logic in a single filter but that is the subject of > another debate. > > >thanks, > >-Mark > > -- > Ceki > > > -- > 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]>
