logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: TImeBasedRollingPolicy behaviour
Date Wed, 31 Aug 2005 16:07:39 GMT

On Aug 31, 2005, at 7:35 AM, K Sunil wrote:
> Hi All,
>
>           I am using Log4j 1.3 alpha build for the development.
>           In this build, I tried to use TimeBasedRollingPolicy,  
> set  below properties
>
>           TimeBasedRollingPolicy f = new TimeBasedRollingPolicy();
>           f.setActiveFileName("rolling.txt");
>           f.setFileNamePattern("rolling.%d.zip");
>           f.activateOptions();
>
>           then setRollingPolicy to RollingFileAppender object.
>
>          r = new RollingFileAppender();
>          r.setRollingPolicy(f);
>          r.setLayout(s);
>           r.activateOptions();
>
>          I am observing different behaviour i.e
>          I am run the program it logs to rolling.txt file
>          Now I change the system time to one day more and rerun the  
> same program.
>
>          Behaviour observed:  It is not rolling the file, instead  
> it is appended to the same rolling.txt file
>
>          Expected behaviour: Should roll up the file with the date  
> appended to file Name.
>
>
>          Please let me know if I have missed any setting or Is the  
> behaviour as I am observing?
>
>
>
> Thanks and Regards,
> Sunil.K


The RollingFileAppender only renames files when a triggering event  
occurs while the application is running.  It does not attempt to  
determine if a triggering event would have occurred during the time  
that the application was inactive.

What you have specified currently says:   Always log to  
"rolling.txt"  If the evaluation of the file name pattern changes  
between logging events, attempt rename the old rolling.txt to the  
previous evaluation of the file name pattern.

If you are running the CVS HEAD, you can remove the setActiveFileName 
() call which will allow the active log file to be generated from the  
file name pattern.  It still would not attempt to imply transitions  
that occurred in the past, but it would likely have the behavior that  
you desired.  It is also more robust since it eliminates the close  
and rename actions.

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message