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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
