logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject RE: More Filter Thoughts
Date Mon, 03 Jun 2002 20:51:58 GMT

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:log4j-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:log4j-dev-help@jakarta.apache.org>


Mime
View raw message