You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Cr...@lotus.com on 2001/07/24 23:14:23 UTC
DailyRollingFileAppender configuration problem
Hi I'm having a problem getting DailyRollingFileAppender to work. The file
is created but not with the DatePattern in the name of the log. Here is
the excerpt from my configuration file:
# utilFile
log4j.appender.utilFile=org.apache.log4j.DailyRollingFileAppender
log4j.appender.utilFile.DatePattern='.'yyyy-MM-dd-HH-mm
log4j.appender.utilFile.File=util.log
log4j.appender.utilFile.layout=org.apache.log4j.PatternLayout
log4j.appender.utilFile.layout.ConversionPattern=%d{yyyy.MM.dd HH:mm:ss z}
%p %t %c{2} - %m%n
While the javadoc does speak somewhat to how to configure the settings for
a DailyRollingFileAppender, they are not explicit. Is there anywhere that
does instruct how to configure the log4j configuration file for the
various Appenders?
Thanks,
-Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Re: Forcing DailyRollingFileAppender to Rollover
Posted by Ceki Gülcü <cg...@qos.ch>.
Mike,
You can read our CVS rep, not write to it.
By the way, my previous answer to your question was misleading. The stuff about period n, n+1 etc. is bullcrap.
The only known problem with DailyRollingFileAppender is the case of a short lived application. In this case, the rolled log file contains entries of the wrong date.
This has been fixed in the latest code in our cvs repository. Regards, Ceki
At 12:58 26.07.2001 -0700, Mike Papper wrote:
>What do you mean by a "HELLO" message - is this some special thing that
>doesnt get logged?
>Also, how would I submit apatch - do I submit it to a person who integrates
>it into the code or do I just go into CVS and do it myself (and break
>everything)?
>
>Also, thanks a lot for your replies to this and past queries.
>
>Mike
>
>----- Original Message -----
>From: "Ceki Gülcü" <cg...@qos.ch>
>To: "LOG4J Users Mailing List" <lo...@jakarta.apache.org>
>Sent: Tuesday, July 24, 2001 11:54 PM
>Subject: Re: Forcing DailyRollingFileAppender to Rollover
>
>
>At 18:00 24.07.2001 -0700, you wrote:
>>Sometimes I have appenders that dont get log messages very often - usually
>>cause they set their thresholds to "error" or above. The
>>DailyRollingFileAppender doesnt work right with these classes cause the
>>files dont get considered for rollover unless a log event has occured -
>>sometimes days after the event. The behaviour I would like to see is for a
>>file to rollover on the hour - if there are any items and not to rollover
>if
>>there are no items.
>
>We had not considered the case where in period n and n+2 there were events
>but not in n+1. This causes the logs in n to be placed in the file
>corresponding to period n+1. Probably not what you want.
>
>On the other hand if logging events are so scarce, why not increase the
>length of the period from an hour to a day?
>
>The solution to this problem is to keep track of the time of the last log
>and roll to the correct file. In other words, in the previous case since the
>last log occurred during period n, roll to file n instead of n+1 in period
>n+2. See what I mean?
>
>>Note that this problem is not fixed using the Roller class - what that does
>>is force a rollover "every so often". What I want is to "ping" the
>subAppend
>>method "every so often" so that it will periodically check whether it needs
>>to rollover or not.
>>
>>I have some of my own Appenders and I implemented a public method called
>>"timeToRollover" in them. I have setup a java.util.Timer (which runs every
>>minute) and a java.util.TimerTask that calls this timeToRollover method of
>>its Appender (but the Appender is really one of my subclasses - so I can do
>>this easily). This way, I have a thread that pokes and prods my Appender
>>every minute to "ask" it to check if it should rollover.
>>
>>However I cannot do this so straightforwardly with the
>>DailyRollingFileAppender class. I could have duplicated what the subAppend
>>method does (except to not log the LoggingEvent) except that the neccessary
>>members are private. I am wondering if calling subAppend with a "bogus"
>>LoggingEvent (constructed with all null objects) will do the trick for me?
>>Kinda like side-effect programming.
>>
>>I was also considering just calling rollOver anyway as it has some code:
>>
>> String datedFilename = fileName+sdf.format(now);
>> if (scheduledFilename.equals(datedFilename))
>> return;
>>
>>that looks like it will almost but not quite "test" before rolling over. I
>>think that calling this will actually result in files that are rolled over
>>too soon. So a given hour may have entries scattered across 2 files. ??
>>
>>Any ideas? Should we add a method named "checkTimeToRollover" to the
>>Appender interface!
>
>The Appender interface has nothing to do with rolling files. It won't be
>changed.
>
>>----------------------- interlude
>>Concerning private members (my opinion): Using private as the default
>access
>>level for member variables and methods closes the door on many things
>>subclasses could do - usually these are things the original writer of the
>>class never envisioned at the time of writing but come to be a need later
>>on.
>>
>>Presumably the writer of DailyRollingFileAppender never concieved of the
>>need for ensuring consistent rollovers. I think all Appenders seem to
>suffer
>>from this problem of not rollingover unles an event is logged. And now that
>>the need is there, I cannot implement via a subclass cause the superclass
>>(DailyRollingFileAppender) uses private members!
>>------------------------------------
>
>You have access to the source code allowing you to change what you do not
>like. You can then supply a patch so that we can integrate your changes to
>the main trunk.
>
>>Note: I cannot just go ahead an log "null" (or innocuous) events as some
>>Appenders have threshold of error - and the sign that these files are EMPTY
>>is used so I can see the system is running smoothly. Having these files
>>populated with a bunch of "null" events would be very annoying.
>
>Have you considered "HELLO" messages?
>
>Thanks for the long and detailed email. Ceki
>
>--
>Ceki Gülcü - http://qos.ch
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-user-help@jakarta.apache.org
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-user-help@jakarta.apache.org
--
Ceki Gülcü - http://qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Re: Forcing DailyRollingFileAppender to Rollover
Posted by Mike Papper <mi...@bodaro.com>.
What do you mean by a "HELLO" message - is this some special thing that
doesnt get logged?
Also, how would I submit apatch - do I submit it to a person who integrates
it into the code or do I just go into CVS and do it myself (and break
everything)?
Also, thanks a lot for your replies to this and past queries.
Mike
----- Original Message -----
From: "Ceki Gülcü" <cg...@qos.ch>
To: "LOG4J Users Mailing List" <lo...@jakarta.apache.org>
Sent: Tuesday, July 24, 2001 11:54 PM
Subject: Re: Forcing DailyRollingFileAppender to Rollover
At 18:00 24.07.2001 -0700, you wrote:
>Sometimes I have appenders that dont get log messages very often - usually
>cause they set their thresholds to "error" or above. The
>DailyRollingFileAppender doesnt work right with these classes cause the
>files dont get considered for rollover unless a log event has occured -
>sometimes days after the event. The behaviour I would like to see is for a
>file to rollover on the hour - if there are any items and not to rollover
if
>there are no items.
We had not considered the case where in period n and n+2 there were events
but not in n+1. This causes the logs in n to be placed in the file
corresponding to period n+1. Probably not what you want.
On the other hand if logging events are so scarce, why not increase the
length of the period from an hour to a day?
The solution to this problem is to keep track of the time of the last log
and roll to the correct file. In other words, in the previous case since the
last log occurred during period n, roll to file n instead of n+1 in period
n+2. See what I mean?
>Note that this problem is not fixed using the Roller class - what that does
>is force a rollover "every so often". What I want is to "ping" the
subAppend
>method "every so often" so that it will periodically check whether it needs
>to rollover or not.
>
>I have some of my own Appenders and I implemented a public method called
>"timeToRollover" in them. I have setup a java.util.Timer (which runs every
>minute) and a java.util.TimerTask that calls this timeToRollover method of
>its Appender (but the Appender is really one of my subclasses - so I can do
>this easily). This way, I have a thread that pokes and prods my Appender
>every minute to "ask" it to check if it should rollover.
>
>However I cannot do this so straightforwardly with the
>DailyRollingFileAppender class. I could have duplicated what the subAppend
>method does (except to not log the LoggingEvent) except that the neccessary
>members are private. I am wondering if calling subAppend with a "bogus"
>LoggingEvent (constructed with all null objects) will do the trick for me?
>Kinda like side-effect programming.
>
>I was also considering just calling rollOver anyway as it has some code:
>
> String datedFilename = fileName+sdf.format(now);
> if (scheduledFilename.equals(datedFilename))
> return;
>
>that looks like it will almost but not quite "test" before rolling over. I
>think that calling this will actually result in files that are rolled over
>too soon. So a given hour may have entries scattered across 2 files. ??
>
>Any ideas? Should we add a method named "checkTimeToRollover" to the
>Appender interface!
The Appender interface has nothing to do with rolling files. It won't be
changed.
>----------------------- interlude
>Concerning private members (my opinion): Using private as the default
access
>level for member variables and methods closes the door on many things
>subclasses could do - usually these are things the original writer of the
>class never envisioned at the time of writing but come to be a need later
>on.
>
>Presumably the writer of DailyRollingFileAppender never concieved of the
>need for ensuring consistent rollovers. I think all Appenders seem to
suffer
>from this problem of not rollingover unles an event is logged. And now that
>the need is there, I cannot implement via a subclass cause the superclass
>(DailyRollingFileAppender) uses private members!
>------------------------------------
You have access to the source code allowing you to change what you do not
like. You can then supply a patch so that we can integrate your changes to
the main trunk.
>Note: I cannot just go ahead an log "null" (or innocuous) events as some
>Appenders have threshold of error - and the sign that these files are EMPTY
>is used so I can see the system is running smoothly. Having these files
>populated with a bunch of "null" events would be very annoying.
Have you considered "HELLO" messages?
Thanks for the long and detailed email. Ceki
--
Ceki Gülcü - http://qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Re: Forcing DailyRollingFileAppender to Rollover
Posted by Ceki Gülcü <cg...@qos.ch>.
At 18:00 24.07.2001 -0700, you wrote:
>Sometimes I have appenders that dont get log messages very often - usually
>cause they set their thresholds to "error" or above. The
>DailyRollingFileAppender doesnt work right with these classes cause the
>files dont get considered for rollover unless a log event has occured -
>sometimes days after the event. The behaviour I would like to see is for a
>file to rollover on the hour - if there are any items and not to rollover if
>there are no items.
We had not considered the case where in period n and n+2 there were events but not in n+1. This causes the logs in n to be placed in the file corresponding to period n+1. Probably not what you want.
On the other hand if logging events are so scarce, why not increase the length of the period from an hour to a day?
The solution to this problem is to keep track of the time of the last log and roll to the correct file. In other words, in the previous case since the last log occurred during period n, roll to file n instead of n+1 in period n+2. See what I mean?
>Note that this problem is not fixed using the Roller class - what that does
>is force a rollover "every so often". What I want is to "ping" the subAppend
>method "every so often" so that it will periodically check whether it needs
>to rollover or not.
>
>I have some of my own Appenders and I implemented a public method called
>"timeToRollover" in them. I have setup a java.util.Timer (which runs every
>minute) and a java.util.TimerTask that calls this timeToRollover method of
>its Appender (but the Appender is really one of my subclasses - so I can do
>this easily). This way, I have a thread that pokes and prods my Appender
>every minute to "ask" it to check if it should rollover.
>
>However I cannot do this so straightforwardly with the
>DailyRollingFileAppender class. I could have duplicated what the subAppend
>method does (except to not log the LoggingEvent) except that the neccessary
>members are private. I am wondering if calling subAppend with a "bogus"
>LoggingEvent (constructed with all null objects) will do the trick for me?
>Kinda like side-effect programming.
>
>I was also considering just calling rollOver anyway as it has some code:
>
> String datedFilename = fileName+sdf.format(now);
> if (scheduledFilename.equals(datedFilename))
> return;
>
>that looks like it will almost but not quite "test" before rolling over. I
>think that calling this will actually result in files that are rolled over
>too soon. So a given hour may have entries scattered across 2 files. ??
>
>Any ideas? Should we add a method named "checkTimeToRollover" to the
>Appender interface!
The Appender interface has nothing to do with rolling files. It won't be changed.
>----------------------- interlude
>Concerning private members (my opinion): Using private as the default access
>level for member variables and methods closes the door on many things
>subclasses could do - usually these are things the original writer of the
>class never envisioned at the time of writing but come to be a need later
>on.
>
>Presumably the writer of DailyRollingFileAppender never concieved of the
>need for ensuring consistent rollovers. I think all Appenders seem to suffer
>from this problem of not rollingover unles an event is logged. And now that
>the need is there, I cannot implement via a subclass cause the superclass
>(DailyRollingFileAppender) uses private members!
>------------------------------------
You have access to the source code allowing you to change what you do not like. You can then supply a patch so that we can integrate your changes to the main trunk.
>Note: I cannot just go ahead an log "null" (or innocuous) events as some
>Appenders have threshold of error - and the sign that these files are EMPTY
>is used so I can see the system is running smoothly. Having these files
>populated with a bunch of "null" events would be very annoying.
Have you considered "HELLO" messages?
Thanks for the long and detailed email. Ceki
--
Ceki Gülcü - http://qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Forcing DailyRollingFileAppender to Rollover
Posted by Mike Papper <mi...@bodaro.com>.
Sometimes I have appenders that dont get log messages very often - usually
cause they set their thresholds to "error" or above. The
DailyRollingFileAppender doesnt work right with these classes cause the
files dont get considered for rollover unless a log event has occured -
sometimes days after the event. The behaviour I would like to see is for a
file to rollover on the hour - if there are any items and not to rollover if
there are no items.
Note that this problem is not fixed using the Roller class - what that does
is force a rollover "every so often". What I want is to "ping" the subAppend
method "every so often" so that it will periodically check whether it needs
to rollover or not.
I have some of my own Appenders and I implemented a public method called
"timeToRollover" in them. I have setup a java.util.Timer (which runs every
minute) and a java.util.TimerTask that calls this timeToRollover method of
its Appender (but the Appender is really one of my subclasses - so I can do
this easily). This way, I have a thread that pokes and prods my Appender
every minute to "ask" it to check if it should rollover.
However I cannot do this so straightforwardly with the
DailyRollingFileAppender class. I could have duplicated what the subAppend
method does (except to not log the LoggingEvent) except that the neccessary
members are private. I am wondering if calling subAppend with a "bogus"
LoggingEvent (constructed with all null objects) will do the trick for me?
Kinda like side-effect programming.
I was also considering just calling rollOver anyway as it has some code:
String datedFilename = fileName+sdf.format(now);
if (scheduledFilename.equals(datedFilename))
return;
that looks like it will almost but not quite "test" before rolling over. I
think that calling this will actually result in files that are rolled over
too soon. So a given hour may have entries scattered across 2 files. ??
Any ideas? Should we add a method named "checkTimeToRollover" to the
Appender interface!
----------------------- interlude
Concerning private members (my opinion): Using private as the default access
level for member variables and methods closes the door on many things
subclasses could do - usually these are things the original writer of the
class never envisioned at the time of writing but come to be a need later
on.
Presumably the writer of DailyRollingFileAppender never concieved of the
need for ensuring consistent rollovers. I think all Appenders seem to suffer
from this problem of not rollingover unles an event is logged. And now that
the need is there, I cannot implement via a subclass cause the superclass
(DailyRollingFileAppender) uses private members!
------------------------------------
Note: I cannot just go ahead an log "null" (or innocuous) events as some
Appenders have threshold of error - and the sign that these files are EMPTY
is used so I can see the system is running smoothly. Having these files
populated with a bunch of "null" events would be very annoying.
Mike Papper
mike@bodaro.com
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org