I propose the following: - new, changed filters under the package name o.a.log4j.filters - In this package, a new abstract base class, ChainableFilterBase.java. This will be a base class that supports a property, ChainPolicy, and a decide() method that uses it's setting. ChainPolicy will support the 4 values we have outlined previously. It is expected that subclasses of this base class will be "chainable" together in a filter chain. - Move the current filter functionality available in o.a.log4j.varia into o.a.log4j.filters, and make them subclasses of the ChainableFilterBase class as needed/required. Previous functionality of the AcceptOnMatch property will not be supported in the new package. - Create new filter classes for filtering on NDC, MDC, logger names, etc.
As noted, we will need to write up some useful documentation to better explain the usage of these filters. -Mark > -----Original Message----- > From: Mark Womack > Sent: Friday, May 31, 2002 9:53 AM > To: 'Log4J Developers List' > Subject: RE: More Filter Thoughts > > > 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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
