I can't speak for Ceki, but here's my 2 cents. Some applications try
very hard to control the number of threads and other resources for
efficiency purposes. For example, application servers are usually
written in this way. In fact, the EJB specification prohibits EJB from
creating their
At 12:22 PM 12/10/2003 +0100, Walid Joseph Gedeon wrote:
I can't speak for Ceki, but here's my 2 cents. Some applications try
very hard to control the number of threads and other resources for
efficiency purposes. For example, application servers are usually
written in this way. In fact,
Hello all!
This is about the fact that the DailyRollingAppender does not roll at
the top-of-the-period that is set, but instead at the first log after
that time has passed.
This issue is the one listed in bug 10560 (DailyRollingAppender does
not roll each period). I thought I might lay
Thank for this patch. It is appreciated. Unfortunately, I don't think
we could include it for the following reasons.
Joseph,
First, the rolling appenders have been rewritten. See o.a.l.rolling
package in log4j cvs. Second, it is not good practice to hide threads
within appenders.
Have you
-Original Message-
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 09, 2003 10:56 AM
To: Log4J Developers List
Subject: Re: DailyRollingAppender does not roll each period (issue)
Second, it is not good
practice to hide threads within appenders.
Just out
Thank you for your reply, Ceki.
First, the rolling appenders have been rewritten. See o.a.l.rolling
package in log4j cvs.
I will refer to the cvs sources (so far I was based on the sources in the
jar). Do the re-written appenders address this issue? I'll probably
self-answer that by reading the
Walid Joseph Gedeon wrote:
Thank you for your reply, Ceki.
First, the rolling appenders have been rewritten. See o.a.l.rolling
package in log4j cvs.
I will refer to the cvs sources (so far I was based on the sources in the
jar). Do the re-written appenders address this issue? I'll probably
