On Sun, Feb 2, 2014 at 3: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... > In this area, I'd like to rename org.apache.logging.log4j.core.appender.rolling.helper to org.apache.logging.log4j.core.appender.rolling.action Thoughts? Gary > > 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 > > > -- E-Mail: [email protected] | [email protected] 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
