Log4j 2
  1. Log4j 2
  2. LOG4J2-696

RegexFilter does not match multiline log messages

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0-rc2
    • Fix Version/s: None
    • Component/s: Filters
    • Labels:
      None

      Description

      RegexFilter is constructed with a pattern, but pattern does not support multiline matches, so impossible for the filter to ever match a multiline msg.
      Should maybe provide a multline="x attribute whichi should default to true and result in the patter being compiled as such:
      Pattern pattern = Pattern.compile(".line.", Pattern.DOTALL);

      See attached UnitTest illustrating failure

        Activity

        phil wray created issue -
        phil wray made changes -
        Field Original Value New Value
        Attachment RegexFilterTest.java [ 12653372 ]
        Hide
        Gary Gregory added a comment -

        We might not be able to use org.apache.logging.log4j.core.config.plugins.util.TypeConverters.PatternConverter if we want to support the int flag for java.util.regex.Pattern.compile(String, int).

        It seems the solution is to change org.apache.logging.log4j.core.filter.RegexFilter.createFilter(Pattern, Boolean, Result, Result) and either:

        • Add an int parameter and let user compute the flag themselves, or
        • Add a String parameter and allow users to say things like "CASE_INSENSITIVE | MULTILINE" but that means parsing such things.

        Perhaps we should just start with an int flag.

        Thoughts?

        Show
        Gary Gregory added a comment - We might not be able to use org.apache.logging.log4j.core.config.plugins.util.TypeConverters.PatternConverter if we want to support the int flag for java.util.regex.Pattern.compile(String, int) . It seems the solution is to change org.apache.logging.log4j.core.filter.RegexFilter.createFilter(Pattern, Boolean, Result, Result) and either: Add an int parameter and let user compute the flag themselves, or Add a String parameter and allow users to say things like "CASE_INSENSITIVE | MULTILINE" but that means parsing such things. Perhaps we should just start with an int flag. Thoughts?
        Hide
        phil wray added a comment -

        Int flag sounds like a better option. Doubt its a common use case. The int
        let's you use all the options and is future compatible without having to
        maintain parsing code and mappings.

        Cheers,
        Phil

        Show
        phil wray added a comment - Int flag sounds like a better option. Doubt its a common use case. The int let's you use all the options and is future compatible without having to maintain parsing code and mappings. Cheers, Phil
        Hide
        Gary Gregory added a comment - - edited

        I committed a version that allows a String[] of Pattern compile option names to be passed in, which match the name of any int defined on the Pattern class. This should be future/past proof to allow you to use whatever is defined on your Java version.

        This is available in trunk.

        Please test it out report how that matches your needs.

        Show
        Gary Gregory added a comment - - edited I committed a version that allows a String[] of Pattern compile option names to be passed in, which match the name of any int defined on the Pattern class. This should be future/past proof to allow you to use whatever is defined on your Java version. This is available in trunk. Please test it out report how that matches your needs.
        Hide
        Gary Gregory added a comment -

        Resolving since no additional comments have been offered.

        Show
        Gary Gregory added a comment - Resolving since no additional comments have been offered.
        Gary Gregory made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Hide
        phil wray added a comment -

        thanks Gary - looks good, even got the pattern name parsing in there.

        Show
        phil wray added a comment - thanks Gary - looks good, even got the pattern name parsing in there.
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Resolved Resolved
        12d 5h 8m 1 Gary Gregory 13/Jul/14 16:36

          People

          • Assignee:
            Unassigned
            Reporter:
            phil wray
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development