Uploaded image for project: 'Log4j 2'
  1. Log4j 2
  2. LOG4J2-2984

Filters configured in Logger aren't applied at all; global filters can't DENY

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Cannot Reproduce
    • 2.0, (28)
      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
    • None

    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:

              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();
              }
      

      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.

        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.

        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.

        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.

      Attachments

        Activity

          samuelm Samuel Martin added a comment -

          I have updated the issue (and the title) to show that the current code doesn't do it well with either Logger's filters or global configuration filters. They might be two separate issues, but they are related to the same code region code}}org.apache.logging.log4j.core.Logger$PrivateConfig.filter(...) {{code.
          Indeed, there is a lot of code shared among the different code}}filter{{code methods, so some refactoring might be addressed if appropriate.
           

          samuelm Samuel Martin added a comment - I have updated the issue (and the title) to show that the current code doesn't do it well with either Logger's filters or global configuration filters. They might be two separate issues, but they are related to the same code region  code}}org.apache.logging.log4j.core.Logger$PrivateConfig.filter(...) {{code . Indeed, there is a lot of code shared among the different code}}filter{{code methods, so some refactoring might be addressed if appropriate.  
          rgoers Ralph Goers added a comment - - edited

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

          rgoers Ralph Goers added a comment - - edited 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 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.
          rgoers Ralph Goers added a comment -

          Is any followup required or did my comment above resolve this issue?

          rgoers Ralph Goers added a comment - Is any followup required or did my comment above resolve this issue?
          samuelm Samuel Martin added a comment -

          What you say seems reasonable. Moreover, I've tried it by I've not been able to trigger again the behaviour I report, so the issue can be closed.

          FWIW: After reporting the bug, I had eventually used a workaround to avoid the need for Logger-attached Filters. Now I have tried to reproduce the error, but I get the filters properly working. I understand it was not isEnabled to blame, maybe there was some other reason (on my side or at Log4J's) that had prevented it from working when I reported it, but the fact is that I'm not able to reproduce it now.

          samuelm Samuel Martin added a comment - What you say seems reasonable. Moreover, I've tried it by I've not been able to trigger again the behaviour I report, so the issue can be closed. FWIW: After reporting the bug, I had eventually used a workaround to avoid the need for Logger-attached Filters. Now I have tried to reproduce the error, but I get the filters properly working. I understand it was not isEnabled to blame, maybe there was some other reason (on my side or at Log4J's) that had prevented it from working when I reported it, but the fact is that I'm not able to reproduce it now.
          rgoers Ralph Goers added a comment -

          Thanks for the quick response! 

          Closing based on reporter feedback.

          rgoers Ralph Goers added a comment - Thanks for the quick response!  Closing based on reporter feedback.

          People

            Unassigned Unassigned
            samuelm Samuel Martin
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: