The current implementation of RFA allows configurations that are not meaningful and have non-intuitive semantics.
Some of the issues come from the fact that the File parameter does not have to have a file portion when there is a datePattern. Example config from a bug report <file value="./output/"/> <datePattern value="'LoggerTest'yyyyMMddHHmm'.log'"/> This configuration actually works in an intuitive manner if staticLogFileName is false. If staticLogFileName is true, it fails miserably and does not log anything due to file creation issues. Given the same configuration with composite rolling, where would you expect the roll index to go with and without PreserveLogFileNameExtension? Current code generates the same files with and without PreserveLogFileNameExtension. It generates LoggerTest201109181715.log LoggerTest201109181715.log.1 etc. To me that is not right. I believe that the .log in the datePattern should be treated as an extension and, if PreserveLogFileNameExtension = true, it should generate something like LoggerTest201109181715.1.log, LoggerTest201109181715.2.log. I do not believe that the current ignoring of PreserveLogFileNameExtension is intentional. It is just a case that was not considered. After having spent two weekends looking at and playing with the code, I have decided that I do not have clear understanding of my target. Given that it appears that I am going to break the internal contract for RFA and the ambiguity in the current implementation it appears that we should create a new RFA. (Perhaps called RollingFileAppender2??) with a clear definition of its semantics. As such I would like to propose 1) - Make CountDirection default to positive 2) - Make PreserveLogFileNameExtension default to true 3) - Any date portion in a file name be prefixed with a . as if it were an extension. 3) - Decide if PreserveLogFileNameExtension applies to both the datePattern and the size roll index or just to the size roll index. I propose that it applies to size roll index and a new parameter (PreserveLogFileBase - defaults to true) be used to apply to the date roll. 4) - Remove the ability to do the sample above. In other words, only allow date editing within the datePattern. The following config would achieve almost same file names. <file value="./output/LoggerTest.log"/> <datePattern value="yyyyMMddHHmm"/> <PreserveLogFileBase value="true"/> Generated file name would look like LogTest.201109181715.log If roll type become composite, then the files would look like LogTest.201109181715.1.log, LogTest.201109181715.2.log 5) - I propose that in the case of a maximum fixed size of roll backups, that the roll index become a fixed width field with leading zeros. Doing so will greatly simplify the deleting during rolling and make the process more robust because the pattern will be specific. Currently the code sort of guesses by employing too many string.StartsWith() calls. Example, if MaxSizeRollBackups is set to 10, then the file names above would be LogTest.201109181715.01.log, LogTest.201109181715.02.log 6) - Include a new MaxDateRollBackups parameter to limit the number of date periods that will be maintained. Doing so is (I believe) currently unfeasible, if not impossible, given the ability to include a file name in the base pattern and not have a file name in the File parameter. 7) - Personally I would feel no loss if StaticFileName went away and was always treated as false, but I expect that many people would want to keep it. ---------------------------------------------------------------------- Roy Chastain
