Ceki,
I worried about the non-existent file problem also, but discovered that the
file is guaranteed to already be open by the time the activateOptions method
is called. I couldn't believe the fix was so simple, and yet seems to be
bulletproof. I can't say that I've run an extreme battery of tests against
the fix, but I have tried most of the obvious ones without running into any
problems. I came up with the fix idea without spending much time looking at
the code to understand how everything works. Then I just ran different
scenarios in the debugger to make sure the fix worked. It's better to be
lucky than good, or so they say... :)
-jon
-----Original Message-----
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 25, 2001 2:08 PM
To: LOG4J Developers Mailing List
Subject: RE: DailyRollingFileAppender problems
Jon,
Frighteningly simple indeed. :-)
What happens if the file named "filename" does not exist? The scheduled file
will be dated 1/1/1970. Hardly what we want. Otherwise, this is the nicest
solution I have seen so far. Regards, Ceki
At 10:07 25.07.2001 -0500, you wrote:
>Actually it doesn't change the name of the current file, just the scheduled
>filename. It works exactly like the other version, except correctly. ;-)
>
>-jon
>-----Original Message-----
>From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, July 25, 2001 1:56 AM
>To: LOG4J Developers Mailing List
>Subject: RE: DailyRollingFileAppender problems
>
>
>This also changes the name of the current file. Something we do not want to
>do. Regards, Ceki
>
>At 21:23 24.07.2001 -0500, Jon Arnett wrote:
>>The fix is frighteningly simple; there's an initialization bug in
>>DailyRollingFileAppender.java. The fix goes into the activateOptions()
>>method as demonstrated below:
>>
>> public
>> void activateOptions() {
>> super.activateOptions();
>> if(datePattern != null && fileName != null) {
>> now.setTime(System.currentTimeMillis());
>> sdf = new SimpleDateFormat(datePattern);
>> int type = computeCheckPeriod();
>> printPeriodicity(type);
>> rc.setType(type);
>>// ****************************************
>>// The bug is fixed in the following line. Instead of
>>"filename+sdf.format(new Date())", use the following:
>> scheduledFilename =
>> fileName+sdf.format(new Date(new File(fileName).lastModified()));
>>// ****************************************
>> } else {
>> LogLog.error("Either Filename or DatePattern options are not set for
>>["+
>> name+"].");
>> }
>> }
>>
>>I posted the patch a few weeks ago, but never heard anything back.
>>
>>-jon
>>-----Original Message-----
>>From: Kevin Steppe [mailto:[EMAIL PROTECTED]]
>>Sent: Tuesday, July 24, 2001 2:07 PM
>>To: LOG4J Developers Mailing List
>>Subject: Re: DailyRollingFileAppender problems
>>
>>Robin,
>> This is a known feature/bug for the DailyRollingFileAppender. You
have
>>two
>>options to get around this. First in the cvs is a
CompositeRollingAppender
>>which will do this for you -- you could also use it as a
>RollingFileAppender
>>or
>>combined, hence Composite. Second, a few weeks back someone posted a
>>different
>>solution that checks and rolls old files.
>>
>>Kevin
>>
>>
>>"Robin Beetge@iCommerce" wrote:
>>
>>> Hi
>>>
>>> I am having the following problem with the DailyRollingFileAppender and
>>was
>>> wondering if this was a bug or whether the behaviour is as it should be.
>>> When using the DailyRollingFileAppender set so that it rolls over every
>>> minute it will only work if I have a program that runs for more than a
>>> minute a writes messages in each of the two minutes that the program
>>spans.
>>> But if I have a quick program that writes a single log message and run
it
>>at
>>> say 13H00 and again at 13H05 then both messages are in the same file
i.e.
>>no
>>> roll over occurs.
>>>
>>> I went through the source code and swithced the debugging for log4j on
>and
>>> confirmed that the code should be operating as above, hence my question
>>> whether this is by design.
>>> I would have expected DailyRollingFileAppender to work as with
>>> RollingFileAppender that will check the file if it is written to from to
>>> seperate programs at different times. i.e. check the timestamp on the
>file
>>> before writing to it if before the next roll over time write else roll
>>over
>>> and then write
>>>
>>> I can see that my way would incur a greater time wastage as you'd have
to
>>> check the file each time you start up.
>>>
>>> hope I make sense.
>>> thanks for the help
>>>
>>> Robin Beetge
>>> Systems Developer
>>> Dimension Data i-Commerce Services
>>> Tel. (021) 9367766
>>> Cell 082 3751665
>>> e-Mail: [EMAIL PROTECTED]
>>> Web www.didata.com
>>>
>>> ---------------------------------------------------------------------
>>> 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]
>>
>>
>>---------------------------------------------------------------------
>>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]
>
>
>---------------------------------------------------------------------
>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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
