Users should extend this class to implement customized logging
event filtering. Note that Category and AppenderSkeleton, the parent class of all standard
appenders, have built-in filtering rules. It is suggested that you
first use and understand the built-in rules before rushing to write
your own custom filters.
This abstract class assumes and also imposes that filters be
organized in a linear chain. The decide(LoggingEvent) method of each filter is called sequentially,
in the order of their addition to the chain.
If the value DENY is returned, then the log event is
dropped immediately without consulting with the remaining
filters.
If the value NEUTRAL is returned, then the next filter
in the chain is consulted. If there are no more filters in the
chain, then the log event is logged. Thus, in the presence of no
filters, the default behaviour is to log all logging events.
If the value ACCEPT is returned, then the log
event is logged without consulting the remaining filters.
The philosophy of log4j filters is largely inspired from the
Linux ipchains.
support filters.
Since:
0.9.0
Author:
Ceki Gülcü
Field Summary
static int
ACCEPT
The log event must be logged immediately without consulting with
the remaining filters, if any, in the chain.
static int
DENY
The log event must be dropped immediately without consulting
with the remaining filters, if any, in the chain.
static int
NEUTRAL
This filter is neutral with respect to the log event.
If the decision is DENY, then the event will be
dropped. If the decision is NEUTRAL, then the next
filter, if any, will be invoked. If the decision is ACCEPT then
the event will be logged without consulting with other filters in
the chain.