You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Mark Womack <mw...@bevocal.com> on 2002/03/28 23:06:41 UTC
[SUBMIT] GenericMatchFilter.java; SetLocationInfoFilter.java
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
RE: Is there a way to use a Level subclass value in a configuration file?
Posted by Gregory Gray <gr...@future-skies.com>.
I read the dtd for configuration files more carefully and saw that you
can specify the Level class when specifying the level.
<level class="mypackage.MyLevel" value="FINER"/>
I figured I'd send the answer in case anyone was interested.
-Greg
-----Original Message-----
From: Gregory Gray [mailto:greg.gray@future-skies.com]
Sent: Thursday, March 28, 2002 5:42 PM
To: 'Log4J Developers List'
Subject: Is there a way to use a Level subclass value in a configuration
file?
My goal is for my code to not care if I'm using Log4j's logger or the
logger from Java 1.4. Even though I'm planning to use Log4j, I want to
be able to change without altering the debugging statements if need be.
It's also key to be able to change the level in the configuration file
on the fly to alter the debugging behavior since restarting the
application is really not an option in the field.
If I use logger.log(Level, message) the same code can use either
library. The problem is that the levels don't match up (except for ALL
and INFO). To allow more levels I created MyLevel (based it on the
XLevel example) to include MyLevel.FINE, MyLevel.FINER, and
MyLevel.FINEST. This works if I code in the setting of the level
(logger.setLevel(MyLevel.FINER)) but it does not pick it up from my
configuration file since the configuration file reader does not know
about the MyLevel subclass. Is there a way to specify this that I'm
missing? If not it would be nice to have an attribute in the config
file to allow you to identify a different Level implementation to use.
I searched through the mailing list archives for information about this
but did not find anything. I apologize if I'm repeating an old
discussion.
Thanks for you attention!
-Greg
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Is there a way to use a Level subclass value in a configuration file?
Posted by Gregory Gray <gr...@future-skies.com>.
My goal is for my code to not care if I'm using Log4j's logger or the
logger from Java 1.4. Even though I'm planning to use Log4j, I want to
be able to change without altering the debugging statements if need be.
It's also key to be able to change the level in the configuration file
on the fly to alter the debugging behavior since restarting the
application is really not an option in the field.
If I use logger.log(Level, message) the same code can use either
library. The problem is that the levels don't match up (except for ALL
and INFO). To allow more levels I created MyLevel (based it on the
XLevel example) to include MyLevel.FINE, MyLevel.FINER, and
MyLevel.FINEST. This works if I code in the setting of the level
(logger.setLevel(MyLevel.FINER)) but it does not pick it up from my
configuration file since the configuration file reader does not know
about the MyLevel subclass. Is there a way to specify this that I'm
missing? If not it would be nice to have an attribute in the config
file to allow you to identify a different Level implementation to use.
I searched through the mailing list archives for information about this
but did not find anything. I apologize if I'm repeating an old
discussion.
Thanks for you attention!
-Greg
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: SetLocationInfoFilter, was: [SUBMIT]
GenericMatchFilter.java; SetLocationInfoFilter.java
Posted by Ceki Gülcü <ce...@qos.ch>.
Hi Mark,
At 14:06 28.03.2002 -0800, Mark Womack wrote:
>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.
Why do you think that calling getLocationInfo multiple times will cost more
than calling it just once?
The implementaiton of LoggingEvent.getLocationInformation is as follows:
public
LocationInfo getLocationInformation() {
if(locationInfo == null) {
locationInfo = new LocationInfo(new Throwable(), fqnOfCategoryClass);
}
return locationInfo;
}
>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.
Not all appenders require the setLocationInfo method and its implementation
is rather trivial. On the other had, the idea of SetLocationInfoFilter is very
original. I'll include it in the contribs/MarkMomack/ directory.
--
Ceki
My link of the month: http://java.sun.com/aboutJava/standardization/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>