logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <rgo...@apache.org>
Subject Re: rolling in log4j2
Date Mon, 03 Feb 2014 00:49:42 GMT
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 <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
>>>>>> 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

View raw message