[ 
https://issues.apache.org/jira/browse/LOG4NET-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13555286#comment-13555286
 ] 

Dominik Psenner commented on LOG4NET-27:
----------------------------------------

If a persistent storage of the file history is not needed, why keep it anyway? 
I think that the implementation of the rolling could always use a persistent 
history somewhere (registry|file|..?) allowing the implementation of fancier 
rolling methods that even combine date, size and arbitrary (random) filenames. 
Currently the rolling is quite limited from that point of view. Since a rewrite 
of the rollingfileappender is in discussion since long time those ideas could 
well make it into there. The discussion took place at 
http://apache-logging.6191.n7.nabble.com/RFA-NG-review-td24505.html and some 
helping hands / comments / reviews are still welcome. Somehow I (and probably 
also Stefan) lost track on the RFA-NG topic since I didn't need it anymore and 
have not enough spare time even if it would resolve a lot of log4net issues.
                
> Rolling files on date/time boundaries doesn't support a maximum number of 
> backup files.
> ---------------------------------------------------------------------------------------
>
>                 Key: LOG4NET-27
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-27
>             Project: Log4net
>          Issue Type: New Feature
>          Components: Appenders
>    Affects Versions: 1.2.11
>            Reporter: Florian Ramillien
>            Priority: Minor
>             Fix For: 1.2 Maintenance Release
>
>         Attachments: LOG4NET-27.patch, RollingFileAppender.cs, 
> RollingFileAppender.cs, RollingFileAppender.cs, RollingFileAppender.cs.patch, 
> RollingFileAppender.patch
>
>
> A maximum of backup files exist when rolling files on file size, but not for 
> rolling on date/time.
> This can be implemented with the same config key : MaxSizeRollBackups

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to