[
https://issues.apache.org/jira/browse/LOG4J2-2984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17280686#comment-17280686
]
Ralph Goers edited comment on LOG4J2-2984 at 2/7/21, 10:21 PM:
---------------------------------------------------------------
It is an incorrect statement to say that Filters attached to Loggers are not
being applied. It is a true statement that only the global filters are taken
into account in the "isEnabled" methods as that calculation must be performed
quickly and trying to find all the relevant filters would be very slow. The
code you referenced above is only used in the isEnabled methods.
If you follow the logic to log an event you will see that the
[LoggerConfig.log|https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-core/src/main/java/org/apache/logging/log4j/core/config/LoggerConfig.java#L480]
method is called which indeed checks the filter. You will notice that this
call is after the LogEvent has been created while the isEnabled methods are
called before a LogEvent has been constructed - which is the primary reason
they are the only filters included in that evaluation.
was (Author: [email protected]):
It is an incorrect statement to say that Filters attached to Loggers are not
being applied. It is a true statement that only the global filters are taken
into account in the "isEnabled" methods as that calculation must be performed
quickly and trying to find all the relevant filters would be very slow. The
code you referenced above is only used in the isEnabled methods.
If you follow the logic to log an event you will see that the[
LoggerConfig.log|https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-core/src/main/java/org/apache/logging/log4j/core/config/LoggerConfig.java#L480]
method is called which indeed checks the filter. You will notice that this
call is after the LogEvent has been created while the isEnabled methods are
called before a LogEvent has been constructed - which is the primary reason
they are the only filters included in that evaluation.
> Filters configured in Logger aren't applied at all; global filters can't DENY
> -----------------------------------------------------------------------------
>
> Key: LOG4J2-2984
> URL: https://issues.apache.org/jira/browse/LOG4J2-2984
> Project: Log4j 2
> Issue Type: Bug
> Components: Configuration, Documentation, Filters
> Affects Versions: 2.0, 2.0.1, 2.0.2, 2.1, 2.2, 2.3, 2.4, 2.4.1, 2.5, 2.6,
> 2.6.1, 2.6.2, 2.7, 2.8, 2.8.1, 2.8.2, 2.9.0, 2.9.1, 2.10.0, 2.11.0, 2.11.1,
> 2.11.2, 2.12.0, 2.12.1, 2.13.0, 2.13.1, 2.13.2, 2.14.0, 2.13.3
> Reporter: Samuel Martin
> Priority: Major
> Labels: Filtering, Logger
>
> According to the documentation, Filters can be applied in different places:
> among others, as global filters applied to the whole configuration, to
> individual Appenders or... to individual loggers. However, when trying to
> configure a filter within a Logger, it doesn't seem to be applied.
> After debugging the issue, I think I have traced it to these lines within
> {{org.apache.logging.log4j.core.Logger$PrivateConfig}} internal class:
> {code:java}
> boolean filter(final Level level, final Marker marker, final String
> msg) {
> final Filter filter = config.getFilter();
> if (filter != null) {
> final Filter.Result r = filter.filter(logger, level, marker,
> msg);
> if (r != Filter.Result.NEUTRAL) {
> return r == Filter.Result.ACCEPT;
> }
> }
> return level != null && intLevel >= level.intLevel();
> }
> {code}
> The first line is retrieving the filter from the global configuration
> {{config.getFilter()}} instead of this logger's filter (if any)
> {{loggerConfig.getFilter()}}. The global configuration filter is applied,
> while the latter is simply ignored.
> Some additional notes follow:
> * The same reasoning applies at least to the other {{filter(...)}} methods
> in the PrivateConfig class.
> * According to the documentation, the {{LoggerConfiguration}}'s level is
> applied before the filters; however, the code above doesn't say exactly the
> same (if the filter result is {{ACCEPT}}, then the event is not filtered,
> regardless the {{LoggerConfiguration}}'s level.
> * If we consider that the {{LoggerConfiguration}} filters have been
> unintentionally ommitted, and the goal of the code was to apply the global
> configuration filters, then the result does not either succeed. According to
> the documentation, if a global configuration filter raises yields an ACCEPT
> or a DENY, the Logger's level is ignored.
> {quote}At the same level as the appenders, loggers and properties elements.
> These filters can accept or reject events before they have been passed to a
> LoggerConfig.
> {quote}
> {quote}Context-wide Filters are configured directly in the configuration.
> Events that are rejected by these filters will not be passed to loggers for
> further processing. Once an event has been accepted by a Context-wide filter
> it will not be evaluated by any other Context-wide Filters nor will the
> Logger's Level be used to filter the event.
> {quote}
> The code above allows this "forcibly ACCEPT" from global filters, but it does
> not allow a "forcible DENY" (they just rely on the Level of the specific
> LoggerConfiguration).
> * This is in practice a duplicate of LOG4J2-1965. I don't know why it was
> closed by the author just after having opened it, nor how it has not been
> fixed since then.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
