log4cplus::spi::Filter Class Referenceabstract

Users should extend this class to implement customized logging event filtering. More...

`#include <filter.h>`

Inheritance diagram for log4cplus::spi::Filter:
[legend]
Collaboration diagram for log4cplus::spi::Filter:
[legend]

## Public Member Functions

| Filter ()
virtual | ~Filter ()
void | appendFilter (FilterPtr filter)
| Appends `filter` to the end of this filter chain.
virtual FilterResult | decide (const InternalLoggingEvent &event) const =0
| If the decision is `DENY`, then the event will be dropped.
Public Member Functions inherited from log4cplus::helpers::SharedObject
void | addReference () const LOG4CPLUS_NOEXCEPT
void | removeReference () const

## Public Attributes

FilterPtr | next
| Points to the next filter in the filter chain.
Public Attributes inherited from log4cplus::helpers::SharedObject
thread::Mutex | access_mutex

## Additional Inherited Members

Protected Member Functions inherited from log4cplus::helpers::SharedObject
| SharedObject ()
| SharedObject (const SharedObject &)
| SharedObject (SharedObject &&)
virtual | ~SharedObject ()
SharedObject & | operator= (const SharedObject &) LOG4CPLUS_NOEXCEPT
SharedObject & | operator= (SharedObject &&) LOG4CPLUS_NOEXCEPT

## Detailed Description

Users should extend this class to implement customized logging event filtering.

Note that the `Logger` and `Appender` classes 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 log4cplus filters is largely inspired from the Linux ipchains.

Definition at line 107 of file filter.h.

## Constructor & Destructor Documentation

## Filter()

log4cplus::spi::Filter::Filter | ( |  | ) |

## ~Filter()

virtual log4cplus::spi::Filter::~Filter | ( |  | ) |

virtual

## Member Function Documentation

## appendFilter()

void log4cplus::spi::Filter::appendFilter | ( | FilterPtr | filter | ) |

Appends `filter` to the end of this filter chain.

## decide()

virtual FilterResult log4cplus::spi::Filter::decide | ( | const InternalLoggingEvent & | event | ) | const

pure virtual

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.

Parameters

  event | The LoggingEvent to decide upon.

Returns
  The decision of the filter.

Implemented in log4cplus::spi::DenyAllFilter, log4cplus::spi::FunctionFilter, log4cplus::spi::LogLevelMatchFilter, log4cplus::spi::LogLevelRangeFilter, log4cplus::spi::MDCMatchFilter, log4cplus::spi::NDCMatchFilter, and log4cplus::spi::StringMatchFilter.

## Member Data Documentation

## next

FilterPtr log4cplus::spi::Filter::next

Points to the next filter in the filter chain.

Definition at line 137 of file filter.h.

The documentation for this class was generated from the following file:

- filter.h