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 18:34:00 UTC

[jira] [Updated] (LOG4J2-2984) Filters are not applied to loggers

     [ 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; 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.

  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 the filter (if any) from this logger {{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 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.


> Filters are not applied to loggers
> ----------------------------------
>
>                 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.14.0
>            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; 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.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)