Ceki, > >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? :-)
Yeah, kind of, except it was more like option 3 below. :-) The idea of simplifying via constants just occurred to me recently. Even if we use the constants, it is still going to take some real explanation/documentation to explain the behavior. > 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. Well, option 1 is really like option 2 (automagic set to NEUTRAL) but with a single method and constants. With option 1, we would still need a DenyAllFilter, which is not a bad thing. Maybe we should have an "EndOfChainFilter" that allows settings for ACCEPT_ALL (ACCEPT/ACCEPT) and DENY_ALL (DENY/DENY). Do we want to support ACCEPT/DENY and DENY/ACCEPT for chains with a single filter? Or require the user of a DenyAll/EndOfChain filter to accomplish the same thing? -Mark -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
