At 22:13 30.05.2002 -0700, [EMAIL PROTECTED] wrote:
> > 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.
>
>I did some quick analysis of the various combinations. If we allow a value
>to be set for matches and nomatches, that is 9 possible combinations. Of
>that 9, the ones that have the same value for match/nomatch aren't very
>interesting (DENY/DENY is the equivalent of deny all). But, interestingly,
>there are only 4 combinations that make sense for filter chains because one
>of the two values is set to NEUTRAL:
>
>match value / nomatch value
> ACCEPT / NEUTRAL (equivalent of OR with a denyall at end of chain)
> DENY / NEUTRAL (? partial OR ?)
> NEUTRAL / ACCEPT (? partial AND ?)
> NEUTRAL / DENY (equivalend to AND)
Absolutely. The meaningful cases all have NEUTRAL on one and only one
side of the coin.
>the other two combinations are:
>
>match value / nomatch value
> ACCEPT / DENY (?accept on match?)
> DENY / ACCEPT (?deny on match?)
These make some sense but only if the filter is last on the chain.
>So, my questions are:
>
>1) Do you think that exposing the match/nomatch return values directly will
>be too confusing? Should we come up with "names" for the various
>combinations that will help users know what they are configuring?
Interesting idea.
Possible names for constants are ACCEPT_ON_MATCH, DENY_ON_MATCH,
ACCEPT_ON_MISMATCH, DENY_ON_MISMATCH. One would write:
filter.setPolicy(Filter.ACCEPT_ON_MATCH);
In an xml script you would write:
<filter class="org.apache.log4j.varia.StringMatchFilter">
<param name="StringToMatch" value="hello" />
<param name="Policy" value="AcceptOnMatch" />
</filter>
The inconvenience with this approach is the likelyhood of typos. As in
<param name="Policy" value="AceptOnMatch" />
which is not that bad as long as we report these misspelled values.
BTW, is this where you wanted to go all along? :-)
>2) Is there another mechanism/design that could be used to better expose the
>underlying feature of filters/filter chains?
>
>-Mark
I like option 1) (setPolicy() method) better but to answer your question,
since the
useful cases always have one NEUTRAL part, setting one value to ACCEPT
or DENY, could automatically set the other value to NEUTRAL. For example,
filter.setOnMatch(Filter.ACCEPT); // mismatch automatically set to NEUTRAL
filter.setOnMismatch(Filter.ACCEPT); // match automatically set to NEUTRAL
This is kind of unfriendly. We are basically saying to the programmer
that he is an idiot and log4j always knows better. Please don't quote
me on that. :-)
A third option is to offer two sethods, setOnMatch and setOnMismatch
without any automagic behavior. Option 1) still looks the cleanest.
--
Ceki
SUICIDE BOMBING - A CRIME AGAINST HUMANITY
Sign the petition: http://www.petitiononline.com/1234567b
I am signatory number 22106. What is your number?
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
