>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.
I expected this and favourite the rewrite of RFA. >As such I would like to propose >1) - Make CountDirection default to positive Should it be modifiable? I'm unsure. >2) - Make PreserveLogFileNameExtension default to true +1, something else does not make sense in 99% of all cases. >3) - Any date portion in a file name be prefixed with a . as if it were >an extension. +1, but one should be able to change the "spacer" character. "." is a nuisance to regex parse a logfile, where "-" is tangentially easier. >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. *hmm* Could we make up an easier configuration as we're touching it already? Just like in 4), I would love to see all rolling configuration stuff in a section named <rollFileConfiguration> that lives near <datePattern>. I.e. something like this: <file value="bla.log"/> <datePattern value="yyyyMMddHHmm" /> <rollFileConfiguration> <rollFileCondition size="5MB" /> <rollFileLimitation maxcount="5" /> </rollFileConfiguration> >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 3) covers this. +1 >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 Extending 4) we could become a: <file value="bla.log"/> <datePattern value="yyyyMMddHHmm" /> <rollFileConfiguration> <rollFilePattern value="##" /> <!-- see string.Format() --> <rollFileCondition size="5MB" /> <rollFileLimitation maxcount="5" /> </rollFileConfiguration> >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. +1 Extending 4) this could become a: <file value="bla.log"/> <datePattern value="yyyyMMddHHmm" /> <rollFileConfiguration> <rollFileCondition when="daily" /> <rollFileLimitation maxcount="5" /> </rollFileConfiguration> >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. What does it anyway? Enlighten me, please! :-) Regards, D.
