Enclosed are two filter classes for possible inclusion in log4j. GenericMatchFilter.java - An abstract base class that can be used to implement other filter classes. Implements the ultimate flexibility in filtering and routing logging events. Developer can set the return value for when there is a match, no match, or when the match cannot be performed (ie the filter was not configured properly). By default a match will return Filter.ACCEPT, a no match will return Filter.DENY, and can't match will return Filter.NEUTRAL. But you can configure the return values via property setters. So, the filter could be configured to return DENY for a match, or NEUTRAL for a match (sending the event to the next filter).
SetLocationInfoFilter.java - A pass thru filter that simply calls
LoggingEvent.getLocationInformation() for every event passed to it. After
calling getLocationInformation, it returns Filter.NEUTRAL to pass the event
to the next filter.
Why?
I found that setting the LocationInfo for every event appended to a
SocketAppender or SocketHubAppender was too expensive. It really bogged
down the system. But while I don't need LocationInfo for all the events, I
would like it for some. There was no way to do this (that I could find),
but these filters let me do it very easily and do it all from the
configuration file.
Also, SetLocationInfoFilter allows the location info to
be set without requiring the appender to support a setLocationInfo() method;
it can all be done in the filters before it gets appended.
I can write a subclass of GenericMatchFilter to match on level (similar to
the current LevelMatchFilter) and another one to match on a (set of) logger
names. Then I could configure a filter chain for my SocketHubAppender to
look something like this:
----------------------
| match level filter |--- no match (DENY)---> exit append
----------------------
|
match
(NEUTRAL)
|
----------------------
| match logger filter |--- no match (ACCEPT)-> append immediately
----------------------
|
match
(NEUTRAL)
|
----------------------
| set loc info filter| (sets loc info for loggers matched by prev filter)
----------------------
|
(NEUTRAL) SetLocationInfoFilter always returns neutral
|
----------------------
| SocketHubAppender |
----------------------
So, if an event meets the configured level filter (1st filter), it will
always be appended. But only the events for Loggers matching the configured
logger name(s) (2nd filter) will have their LocationInfo set (3rd filter).
I'm sure that GenericMatchFilter could be used for a lot of different
things. It supports the utmost flexibility for subclasses to take advantage
of, but maintains (I think) the simplicity of the filter design.
Does this make sense? Do you think it would be useful in general?
-Mark
GenericMatchFilter.java
Description: Binary data
SetLocationInfoFilter.java
Description: Binary data
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
