filter proposal

[Mark Womack <mw...@bevocal.com>]

Now that I have written some test cases for the filters in the varia
directory, I feel I have a much better understanding of them.  So, now I
understand some of the comments about the filter extensions I previously
submitted for submission.  They were a bit overkill in their design and did
pretty much the same thing.

But I still think there are some useful changes that can be made in this
area.

1) If the get/setAcceptOnMatch methods and a decide() method that uses the
set values are moved to an abstract base class, then that base class could
be used by any developer to develop their own filters that are easy to plug
into this filter chain.  LevelRangeFilter and LevelMatchFilter would be
changed to descend from this base class and there would be no affect/change
to their current api.

2) Implement more filters using the abstract base class: NDCMatchFilter,
MDCMatchFilter, LoggerMatchFilter, etc.  Again, they would be easily
compatible with the other filters of this type, using the same
get/setAcceptOnMatch methods in the base class.

3) I would like to add my SetLocationInfoFilter to the set as well.  It
would not use the base class since it is just a pass-thru type filter.

4) Test cases for all of the above.

If folks agree, I will get started in this shortly.  After this I would like
to start exploring the watchdog/reconfiguration area.

-Mark

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>