I hate to be pedantic but ChainableFilterBase is a bad name because the o.a.log4j.spi.Filter class is already "ChainableFilterBase." The o.a.log4j.spi.Filter class is an abstract class supporting precisely the "chainable filter" behavior. It is also a "base" class because all filters derive from it. (Again Filter is an abstract class not an interface.)
Consequently, either 1) we change Filter to become an interface, with FilterBase supporting chaining of filters or 2) we find a different name for ChainableFilterBase, for example BasicFilter or FilterCore. The second option seems somewhat wiser because the basic notion of chaining filters is not being challenged. More comments in line: At 10:40 03.06.2002 -0700, you wrote: >I propose the following: > >- new, changed filters under the package name o.a.log4j.filters +1 >- 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. See my first comment. >- 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. +1 subject to reservation on the class name "ChainableFilterBase". >- Create new filter classes for filtering on NDC, MDC, logger names, etc. +1 >As noted, we will need to write up some useful documentation to better >explain the usage of these filters. +1 >-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 -- 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]>
