(Hello. It's the first time I post here. I hope it's the correct place to put my request. If it's not the case, please accept my apologies and tell me where it should go (e.g. log4j-dev or bugzilla).)
It's been a long time now that I was trying to solve a problem I had with RollingFileAppender's (first with o.a.l.RollingFileAppender (RFA), then with o.a.l.DailyRollingFileAppender (DRFA)). The problem was that from time to time, old versions of the log file were lost at the moment they were renamed. It took me a long time before I could find comments about this problem on the mailing list, then in bugzilla. The more accurate description of the problem I found is in bug 29726. [ http://issues.apache.org/bugzilla/show_bug.cgi?id=29726 ] (And the problem actually comes from Java bug 4167147 [ http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4167147 ].) To make it short, here under is my understanding on the current situation in log4j, and then some suggestions for the developers. Current situation: (A) The problem has been fixed for RFA, *but not DRFA* (since 1.2.15 on 2007-08-24, cf. bug 41735, r513638) (B) The problem was also solved in branch 1.3 with the introduction of o.a.l.rolling.RollingFileAppender. RFA and DRFA were kept as in 1.2 (because of bug 39023), but they were marked as deprecated, with a link to o.a.l.rolling.RollingFileAppender (C) Now, branch 1.3 has been abandoned and o.a.l.rolling has been moved to companions/extras, which is delivered separately from core 1.2. (And in 1.2, RFA and DRFA are *not* deprecated.) (I took the liberty to add a summary of this information to bug 29726.) Suggestions (to avoid other people loosing their time like me): [1] Documentation of RFA and DRFA should warn of the potential problems under Windows [2] Same fix as (A) could be applied on DRFA [3] o.a.l.rolling.RollingFileAppender could be moved from extras to core (if quality is good enough?) (But maybe this requires too much modifications?) [4] RFA and DRFA could be marked as deprecated in v1.2 too (but maybe this would require [3] first). IMHO, at least [1] and [2] could be feasible for next release... -- Arnauld Van Muysewinkel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
