A couple of comments. JDK 1.3 comes with timer classes in
java.util.Timer and TimerTask. They don't have the functionality of cron
but that could be built on top if necessary. Using the timer
infrastructure of java.util has the advantage that fewer threads will be
created overall in a system, and also it just makes sense to use JDK
functionality when it's there. Sure some folks aren't using JDK 1.3 --
maybe there's a downloadable library that implements the java.util timer
functions like there is for the collections lib.
Also, I think that when using rolling log files one would usually like
to roll over on boundaries and not just with a certain periodicity [if
that's even a word]. For example, one might want to roll over daily at
midnight, rather than just daily at the time the server happened to be
restarted at last.
Anders
Ceki Gulcu wrote:
>
> Jim,
>
> Ooops! I got a DateRollingAppender from you too? Eirik Lygre has also sent
> me one. Roberto Leong has too. Their contributions are attached.
> Jim, can you please repost your contribution on this list? I seem to have
> lost it. Sorry, I haven't been handling this item particularly well.
>
> What I would like to see is the following:
>
> 0) Keep in mind that log4j is not in the quickie business. Much of the
> success of the package can be attributed to solving problems well, not just
> solving them.
>
> 1) The new appender should have flexible way of expressing the rollover
> frequency, perhaps in the same format as in the Unix crontabs file which I
> belive is also a Posix standard. I am not aware of any library that
> supports this. JDring (http://webtools.dyade.fr/jdring/) seems to have most
> of the functionality needed except parsing the crontab format. Anyone know
> anything better?
>
> As a side note, the omission of a crontab/at functionality in Java core
> libraries seems like a major oversight. Try buying stock a day later then
> what the customer ordered. See how many customers stay with your brokerage
> house. :-)
>
> 2) The new appender should not add any significant overhead to the append
> method. If appending to a file takes 100 microseconds in a particular
> environment it should still take 100 microseconds with the new appender.
>
> There are several possible designs. The first one is to check for the
> rollover condition at each append. This is what Eirik Lygre has done. The
> second one is to schedule a thread that will initiate the rollover after
> the appropriate delay. This is what Roberto Leong has proposed.
>
> The second approach seems more sound to me. One could generalize it by
> using a single timer thread (as in JDring) to manage multiple time based
> RollingAppenders. Your opinion/comments are welcome. Ceki
>
> ps: I am forwarding this to the Avalon list since they are writing a
> general purpose framework.
> ps: I wonder how Tomcat addresses the issue.
>
> At 21:45 18.01.2001 -0500, you wrote:
> >Yes, but you need to use a different Appender than FileRolloverAppender.
> >I've already written one, but haven't heard back from Ceki about adding it
> >to the "package" yet...
> >
> >-Jim Moore
> >
> >-----Original Message-----
> >From: Andrewt Tierney [mailto:[EMAIL PROTECTED]]
> >Sent: Thursday, January 18, 2001 8:02 PM
> >To: '[EMAIL PROTECTED]'
> >Subject: Rollover for each day ? Is this possible ??
> >
> >
> >
> >I see you can set the maxsize and have it automatically rollover the log
> >file.
> >
> >Is it possible to force a new log file each day ????
> >
> >Thanks
> >Andrew
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---
> Freedom as in the capacity to exercise choice.
>
> ------------------------------------------------------------------------
> Name: DailyFileAppender.java
> DailyFileAppender.java Type: Plain Text (text/plain)
> Encoding: quoted-printable
>
> DailyFileAppender1.javName: DailyFileAppender1.jav
> Type: Plain Text (text/plain)
>
> ------------------------------------------------------------------------
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
