On May 23, 2005, at 6:58 PM, Paul Smith wrote:
Hi Curt, I'm just looking at bug 34979, and it says "...suggested during the port of those classes to log4jcxx'.
Sorry, that was a little cryptic. Porting the log4j 1.3 RollingFileAppender framework to log4cxx (http://issues.apache.org/ jira/browse/LOGCXX-52) is a blocking bug for the next log4cxx release. The old log4cxx RFA's mimicked the log4j 1.2 RFA's and were intimately tied into the previous implementation of FileAppender which got gutted in the migration of Apache Portable Runtime, so it seemed best to drop them and start over with an implementation based on the log4j 1.3 framework.
I finally got started on the porting the code over and after I got the skeleton laid in log4cxx and started moving the guts over I kept running into things that suggested that I stop and go back and do a thorough code review of the log4j code before attempting the port. The first significant issue was the substantial duplication of functionality between org.apache.log4j.pattern.PatternParser and the former org.apache.log4j.rolling.helper.FileNamePattern.parse and org.apache.log4j.pattern.DatePatternConverter and the former org.apache.log4j.rolling.helper.DateTokenConverter. After taking a shot at refactoring the o.a.l.pattern code so that the overlapping o.a.l.rolling.helper code be eliminated, I filed bug 34979 leaving it open ended since I assumed that I would likely find other things in the code review and committed those changes.
I don't recall (emphasis on recall) seeing anything about async'ing the compression. Can you provide me some links to refresh my memory? I think this is a good idea, it's just a reasonable chunk of work, and async stuff can be complicated.
After completing the refactoring of the pattern code, I went back and read the mailing list archives and open bug reports on the rolling file appenders. Async compression was raised in http:// marc.theaimsgroup.com/?l=log4j-user&m=109144092332509&w=2 last August. The issues raised there did seem legitimate and difficult to address with the current interface definitions.
After reworking the interface signatures to anticipate deferred compression, it didn't seem like that much more work to actually implement it and obviously that is the more convincing way to prove that interface reworks were sufficient. If I missed something and it isn't stable, it is pretty simple to either add a configuration option to select async or not or just hardwire to do the compression synchronously. All that should need to be changed is the list that that the compression actions are added to in the RollingPolicy.rollover method.
I was hoping to stabilise the Whatever1.3ReleaseIsCalled to a minimum.
Before we go beta, I think we should do a systematic code review and if we need to make changes we should do them before freezing the API. I don't think that I would have approached these issues differently if I had reviewed the code as part of the push to beta, but the timing was accelerated by the need to port the code to log4cxx.
On the RFA's, the only other thing on my wish list would be the issue raised in http://marc.theaimsgroup.com/?l=log4j- dev&m=110244724207473&w=2 where a maximum number of retained files could be specified for a TimeBasedRollingPolicy. I'm uneasy about calling it MaxBackupIndex since it would really be a count and would approach the implementation differently, but it seems like a good idea.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
