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ü" <[EMAIL PROTECTED]>
>To: "LOG4J Users Mailing List" <[EMAIL PROTECTED]>
>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: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
--
Ceki Gülcü - http://qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
