> You mean setMatchReturnVal(String val) where val is one of "ACCEPT",
> "DENY" or "NEUTRAL". Same for setMismatchVal(). Correct?
Yes. Sorry, I meant to use the filter return value as the argument. This
is very much like the earlier filters I submitted, but it gets rid of the
setCantMatchVal() method which is not really needed.
Filters using these methods could default to ACCEPT for match and NEUTRAL
for mismatch, which would create an OR filter chain by default. But, you
could use the configuration to change the behavior to AND very easily.
Using your previous example:
<filter class="org.apache.log4j.filters.StringMatchFilter">
<param name="StringToMatch" value="hello" />
<param name="MatchReturnVal" value="NEUTRAL" />
<param name="MismatchReturnVal" value="DENY" />
</filter>
<filter class="org.apache.log4j.filters.StringMatchFilter">
<param name="StringToMatch" value="world" />
<param name="MatchReturnVal" value="NEUTRAL" />
<param name="MismatchReturnVal" value="DENY" />
</filter>
would only accept strings that contain both "hello" and "world". The OR
version would simply be:
<filter class="org.apache.log4j.filters.StringMatchFilter">
<param name="StringToMatch" value="hello" />
</filter>
<filter class="org.apache.log4j.filters.StringMatchFilter">
<param name="StringToMatch" value="world" />
<param name="MismatchReturnVal" value="DENY" />
</filter>
Note that it uses the SAME filter class for both cases, and the
DenyAllFilter is not required since the last filter can be configured to
deny on a mismatch.
Anyway, is it just a proposal. It is very flexible, but another proposal
could easily make better sense. It would be nice to have some properties
with names and/or values that are more explanatory of the configured
behavior but set the match/nomatch values to correct Filter values.
-Mark
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
