The actions originated with the Log4j1 extended design and code. I started from that and then tried to merge the rollover strategies into something that made sense to me. That doesn't mean it can't be changed.
Sent from my iPad > On Feb 2, 2014, at 12:11 AM, Remko Popma <[email protected]> wrote: > > Yes, I was thinking along similar lines. > > Something like https://issues.apache.org/jira/browse/LOG4J2-491 > but perhaps more general. > > I haven't got it all worked out yet but I find the current > DefaultRolloverStrategy difficult to unit-test. E.g., file deletes are not > actions, but renaming and zipping are actions. > It would be nice to separate the logic that generates the "action plan" > from the execution of that action plan. That would facilitate unit testing > and perhaps make it easier to let users insert their own actions in the > chain. Determining deletion candidate files could be part of the logic that > generates the action plan. > Sorry if this all sounds a bit vague atm. Need to think about this some > more... > > >> On Sunday, February 2, 2014, Gary Gregory <[email protected]> wrote: >> >> Perhaps a different approach would be to have a separate clean up object >> that you give a pattern and an age. This would let you separate the >> rollover concern from the clean up. >> >> Gary >> >> >> On Sat, Feb 1, 2014 at 11:02 PM, Remko Popma <[email protected]> >> wrote: >> >>> I see. Basically, you are trying to avoid deleting files that were not >> the >>> result of a rollover, is that correct? >>> I don't have a good answer to that yet. >>> >>> Another use case is patterns like this: >>> filePattern="logs/%d{yyyy-MM}/app-%d{yyyy-MM-dd}.%i.log" >>> where the directory name is or contains a date pattern. So just using the >>> fixed text prefix part of the filePattern is not sufficient to achieve >> your >>> goal... >>> >>> Alternatively, >>> filePattern="logs/%d{yyyy-MM}/webapp42/app-%d{yyyy-MM-dd}.%i.log" >>> where the directory with the date pattern is not the parent directory of >>> the rolled over log files. >>> >>> So I thought we should limit the scan to the directory containing the >>> rolled over log files... >>> >>> Obviously, if the parent directory is a pattern that changes every month, >>> having a "maxAge=2M" (2 months) would never result in a match if we only >>> scan the directory holding the rolled over log files, so older log files >>> would never get deleted. That should not be a problem though. >>> >>> Hm... The only way I can think of to avoid deleting files that were not >> the >>> result of rollover is by pattern matching on the name... >>> I was hoping to avoid that by simply defining the functionality as "any >>> file in that directory is a candidate for deletion", but I guess this may >>> be surprising for users... >>> >>> >>> >>> >>>> On Sun, Feb 2, 2014 at 12:13 PM, Kireet <[email protected]> wrote: >>>> >>>> That wouldn't be ideal for me as I have several different log files >> being >>>> produced in the same directory, but I do see how it would get pretty >>>> complicated to pattern match old files to delete selectively. I could >>>> separate things by folder I guess. What about at least filtering the >>> files >>>> by everything up until the first pattern? E.g. for the below >>>> "app-%d{yyyy-MM-dd}.%i.log", what about only deleting files that start >>> with >>>> app- and are older than the maxAge? >>>> >>>> >>>>> On 2/1/14 6:59 PM, Remko Popma wrote: >>>>> >>>>> Agreed that this seems a common use case. Looking at the >>>>> LOG4J2-435<https://issues.apache.org/jira/browse/LOG4J2-435> ticket, >>>>> >>>>> you're now the third person asking for this feature... >>>>> >>>>> Team, what about adding a maxAge attribute to DefaultRolloverStrategy? >>> The >>>>> attribute would accept values like "3d" (delete older than 3 days), >>>>> similarly "4w" (4 weeks), "5M" (5 months) etc. >>>>> The scanned directory would be the parent dir of the rolled over file >>>>> specified by the {{filePattern}} attribute, and any file in that >>> directory >>>>> would be candidates for deletion. >>>>> >>>>> Thoughts? >>>>> >>>>> >>>>> On Sunday, February 2, 2014, Arkin Yetis <[email protected]> >> wrote: >>>>> >>>>> I had opened the following for this: >>>>>> https://issues.apache.org/jira/browse/LOG4J2-435 >>>>>> Perhaps you can see if this would meet your need and vote for/watch >> it, >>>>>> if >>>>>> it does. >>>>>> >>>>>> >>>>>> On Sat, Feb 1, 2014 at 11:39 AM, Kireet <[email protected] >>> <javascript:;>> >>>>>> >>>>>> wrote: >>>>>> >>>>>> Thanks for the update. So I would need to use an external process to >>>>>> clean >>>>>> >>>>>>> up older files? This seems like a pretty common use case though >> right? >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 2/1/14 12:19 AM, Remko Popma wrote: >> -- >> E-Mail: [email protected] <javascript:;> | >> [email protected]<javascript:;> >> Java Persistence with Hibernate, Second Edition< >> http://www.manning.com/bauer3/> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >> Spring Batch in Action <http://www.manning.com/templier/> >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
