[ http://jira.qos.ch/browse/LBCORE-41?page=com.atlassian.jira.plugin.system.is... ] Patrick Crocker commented on LBCORE-41: --------------------------------------- I too believe that logback should not be establishing arbitrary policy as to what is 'too big' for the FixedWindowRollingPolicy. I replaced commons-logging/log4j with slf4j/logback-classic on an existing project. The log4j rules were already established with a rolling policy of 100 backups. The only way I was able to complete the logback conversion was to copy the original logback FixedWindowRollingPolicy class into a new com.company.FixedLargeWindowRollingPolicy class with the MAX_WINDOW_SIZE code removed. As logback updates to the FixedWindowRollingPolicy class have come out, I've had the task of manually updating my copy with the latest updates. That has changed now that 0.9.29 changed the FixedWindowRollingPolicy class to reference a package-scoped RollingPolicy.Base.zipEntryFileNamePattern field. Since the field is package-scoped, the only way I can keep my hack current is to change my classes package to match the RollingPolicyBase package (ch.qos.logback.core.rolling). This is getting way too messy now. Can't we just have the limitation removed and leave it up to the business to decide how big a window is too big?

FixedWindowRollingPolicy MAX_WINDOW_SIZE too small? ---------------------------------------------------

Key: LBCORE-41 URL: http://jira.qos.ch/browse/LBCORE-41 Project: logback-core Issue Type: Improvement Components: Rolling Affects Versions: unspecified Environment: Operating System: Windows Platform: All Reporter: Mike Mansell Assignee: Logback dev list Priority: Minor

I know it's not a blog but let me first say I've switched from log time use of JCL / log4j and think SLF4J / Logback is awesome so kudos to you guys for getting this out here... simple and powerful.. not much to not like ;-) I'm curious as to why a window size as small as 12 was chosen here. I realize the renaming of all files within the window gets more expensive as the window increases but it seems prohibitive for people with larger logging requirements. Moreover, the fact that it is final means I can't override this either although I realize it is rather trivial to build my own implementation. I have a project that generates a tremendous amount of logging currently (about 100MB every 6 minutes) and in my current setup have issues with files over 2GB. With the current MAX_WINDOW_SIZE I can only keep a days worth of logs! If the rename is a big deal a rolling policy that just uses the index as a cyclic sequence should work fine or are there other reasons to cap this at something so low? I could submit an implementation back if you like but just curious to get your feedback and any reasoning I might be missing on keeping the window size so low. Thanks again for a great product!

-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira