Log4net
  1. Log4net
  2. LOG4NET-66

PreserveFileExtension with StaticFileName

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.2.10
    • Fix Version/s: 1.2.11
    • Component/s: Appenders
    • Labels:
      None
    • Environment:
      Windows Server 2003

      Description

      I found that the patch to make all RollingFileAppender log files have the same file extension (provided by Joshua Bassett) didn't work properly if the log4net configuration used a static file name.

      I've attached a patch to version 312319 with his changes and mine merged.

      Mike

      1. rollingFileAppender.diff
        12 kB
        Mike Blake-Knox
      2. RollingFileAppender.diff
        14 kB
        Mike Blake-Knox

        Issue Links

          Activity

          Hide
          Mike Blake-Knox added a comment -

          see body of Issue

          Show
          Mike Blake-Knox added a comment - see body of Issue
          Hide
          Ron Grabowski added a comment -

          I don't like the idea of using a regular expression to match filenames:

          "^" + Path.GetFileNameWithoutExtension(baseFileName) + "(\\.[0-9]*)?
          " + Path.GetExtension(baseFileName) + "$"

          Wouldn't these filenames cause the regular expression to misbehave (square brackets, parenthesis, and the period have special meaning in regular expressions)?

          log[2.0].txt
          log[2.0].txt.1
          log[2.0].txt.2
          log(1.1).txt
          log(1.1).txt.1
          log(1.1).txt.2
          log(1.1).txt.3

          I suppose writing another helper method would solve the problem:

          RegexEncode(Path.GetFileNameWithoutExtension(baseFileName))

          Is there a way to use DirectoryInfo's GetFiles style searching (DOS wildcards) to achieve the same result?

          Show
          Ron Grabowski added a comment - I don't like the idea of using a regular expression to match filenames: "^" + Path.GetFileNameWithoutExtension(baseFileName) + "(\\. [0-9] *)? " + Path.GetExtension(baseFileName) + "$" Wouldn't these filenames cause the regular expression to misbehave (square brackets, parenthesis, and the period have special meaning in regular expressions)? log [2.0] .txt log [2.0] .txt.1 log [2.0] .txt.2 log(1.1).txt log(1.1).txt.1 log(1.1).txt.2 log(1.1).txt.3 I suppose writing another helper method would solve the problem: RegexEncode(Path.GetFileNameWithoutExtension(baseFileName)) Is there a way to use DirectoryInfo's GetFiles style searching (DOS wildcards) to achieve the same result?
          Hide
          Mike Blake-Knox added a comment -

          On 3/1/06, Ron Grabowski (JIRA) <jira@apache.org> wrote:
          > [ http://issues.apache.org/jira/browse/LOG4NET-66?page=comments#action_12368446 ]
          >
          > Ron Grabowski commented on LOG4NET-66:
          > --------------------------------------
          >
          > I don't like the idea of using a regular expression to match filenames:

          It is a bit heavy handed anyway. I'll try to remove it and post a new patch against the current version.

          > "^" + Path.GetFileNameWithoutExtension(baseFileName) + "(\\.[0-9]*)?
          " + Path.GetExtension(baseFileName) + "$"
          >
          > Wouldn't these filenames cause the regular expression to misbehave (square brackets, parenthesis, and the period have special meaning in regular expressions)?

          Regular expressions allow you to match against source text including its special characters by prefixing the special character in the pattern with a back-slash.

          >
          > log[2.0].txt
          > log[2.0].txt.1
          > log[2.0].txt.2
          > log(1.1).txt
          > log(1.1).txt.1
          > log(1.1).txt.2
          > log(1.1).txt.3
          >

          Filenames with numeric extensions should never be generated when preserveFileNameExtension is used. Maybe it needs warning text (like that for staticFileName) highlighting that strange things need to happen if you don't clear the directory first.

          > Is there a way to use DirectoryInfo's GetFiles style searching (DOS wildcards) to achieve the same result?

          Not that I've thought of.

          What might have been better is to explicitly specify the extension to be used and to remove the extension from the base filename. This would probably fit in somewhat better with the original (non-extension preserving code) and might even reduce overhead.


          Mike Blake-Knox

          Show
          Mike Blake-Knox added a comment - On 3/1/06, Ron Grabowski (JIRA) <jira@apache.org> wrote: > [ http://issues.apache.org/jira/browse/LOG4NET-66?page=comments#action_12368446 ] > > Ron Grabowski commented on LOG4NET-66 : > -------------------------------------- > > I don't like the idea of using a regular expression to match filenames: It is a bit heavy handed anyway. I'll try to remove it and post a new patch against the current version. > "^" + Path.GetFileNameWithoutExtension(baseFileName) + "(\\. [0-9] *)? " + Path.GetExtension(baseFileName) + "$" > > Wouldn't these filenames cause the regular expression to misbehave (square brackets, parenthesis, and the period have special meaning in regular expressions)? Regular expressions allow you to match against source text including its special characters by prefixing the special character in the pattern with a back-slash. > > log [2.0] .txt > log [2.0] .txt.1 > log [2.0] .txt.2 > log(1.1).txt > log(1.1).txt.1 > log(1.1).txt.2 > log(1.1).txt.3 > Filenames with numeric extensions should never be generated when preserveFileNameExtension is used. Maybe it needs warning text (like that for staticFileName) highlighting that strange things need to happen if you don't clear the directory first. > Is there a way to use DirectoryInfo's GetFiles style searching (DOS wildcards) to achieve the same result? Not that I've thought of. What might have been better is to explicitly specify the extension to be used and to remove the extension from the base filename. This would probably fit in somewhat better with the original (non-extension preserving code) and might even reduce overhead. – Mike Blake-Knox
          Hide
          Nicko Cadell added a comment -

          This is an enhancment and reworking of the patch submitted as part of LOG4NET-64

          Show
          Nicko Cadell added a comment - This is an enhancment and reworking of the patch submitted as part of LOG4NET-64
          Hide
          Mike Blake-Knox added a comment -

          I've updated the changes so they don't use regular expressions.

          Show
          Mike Blake-Knox added a comment - I've updated the changes so they don't use regular expressions.
          Hide
          Ron Grabowski added a comment -

          Did you run the test cases on this patch? I'm working on combining LOG4NET-64 and LOG4NET-66 and the tests are failing. If everything worked ok for you then I may have missed something...I had to manually apply the patches.

          Show
          Ron Grabowski added a comment - Did you run the test cases on this patch? I'm working on combining LOG4NET-64 and LOG4NET-66 and the tests are failing. If everything worked ok for you then I may have missed something...I had to manually apply the patches.
          Hide
          Ron Grabowski added a comment -

          Fixed as part of LOG4NET-64 in r707809.

          Show
          Ron Grabowski added a comment - Fixed as part of LOG4NET-64 in r707809.

            People

            • Assignee:
              Ron Grabowski
              Reporter:
              Mike Blake-Knox
            • Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development