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]>
