You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@logging.apache.org by "Samuel Martin (Jira)" <ji...@apache.org> on 2020/12/27 20:35:00 UTC
[jira] [Updated] (LOG4J2-2984) Filters configured in Logger aren't
applied at all; global filters can't DENY
[ https://issues.apache.org/jira/browse/LOG4J2-2984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Samuel Martin updated LOG4J2-2984:
----------------------------------
Description:
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.
was:
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; but 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.
* 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.
Summary: Filters configured in Logger aren't applied at all; global filters can't DENY (was: Filters are not applied to loggers)
> 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)