logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: rolling in log4j2
Date Tue, 04 Feb 2014 05:23:18 GMT
On Sun, Feb 2, 2014 at 7:49 PM, Ralph Goers <rgoers@apache.org> wrote:

> 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.
>

It feels like a neat focused package. I would not like a generic 'helper'
package to become a dumping ground or kitchen sink for other stuff.

I think I'll change in the AM.

Gary


> Sent from my iPad
>
> > On Feb 2, 2014, at 12:11 AM, Remko Popma <remko.popma@gmail.com> 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 <garydgregory@gmail.com>
> 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 <remko.popma@gmail.com>
> >> 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 <kireet@feedly.com> 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 <arkinyetis@gmail.com>
> >> 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 <kireet@feedly.com
> >>> <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: garydgregory@gmail.com <javascript:;> | ggregory@apache.org
> <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: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message