Users should extend this class to implement customized logging
event filtering. Note that {@link org.apache.log4j.Category} and {@link
org.apache.log4j.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 {@link #decide
decide(LoggingEvent)} method of each filter is called sequentially,
in the order of their addition to the chain.
The {@link #decide decide(LoggingEvent)} method must return one
of the integer constants {@link #DENY}, {@link #NEUTRAL} or {@link
#ACCEPT}.
If the value {@link #DENY} is returned, then the log event is
dropped immediately without consulting with the remaining
filters.
If the value {@link #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 {@link #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.
Note that filtering is only supported by the {@link
org.apache.log4j.xml.DOMConfigurator DOMConfigurator}. The {@link
org.apache.log4j.PropertyConfigurator PropertyConfigurator} does not
support filters. |