Since I alluded to my efforts in the "Shut off internal logger
output" thread in log4j-user, I thought I'd give a quick heads up.
After I addressed the problems that were causing the log4j 1.2 unit
tests to fail with later JVM's due to changes in stack trace in
logged exceptions (http://issues.apache.org/bugzilla/show_bug.cgi?
id=35519), I made a quick experiment to run the log4j 1.2 unit tests
against the log4j CVS HEAD. In my first attempt, I checked out,
built and tested a CVS HEAD version and a v1_2branch version. The
copied the CVS HEAD version and replaced the tests directory with the
contents from the v1_2branch and ran the tests (needed to specify -
Dproject.classes.home=../classes since the build location had
changed) which immediately resulted in a java.lang.VerifyError which
pretty conclusively suggests that log4j CVS HEAD isn't a drop in
replacement for log4j 1.2 at the moment.
Backing off from binary compatibility, I took a shot at source
compatibility and didn't do much better out of the box. The most
common problem was in unit tests that references filters in
org.apache.log4j.varia which have since moved to
org.apache.log4j.filters. To address these, I added classes to
o.a.l.varia which derived from the o.a.l.filters implementation but
were marked deprecated. Another common compile problem was
unnecessary imports of "org.apache.log4j.performance.NullAppender".
This class is not actually used by the tests and was not included in
the log4j 1.2.x jars (its NullAppender was in a different package),
so I just removed the import.
DRFATestCase in not really a test of the DailyRollingFileAppender but
a test of its non-public nested class RollingCalendar. Since the
only code that could directly access RollingCalendar are in the
org.apache.log4j package, I do not see this as a part of log4j's
public API. So I've added a new target "runExternal" that runs all
tests but DRFATestCase.
MyPatternLayout and MyPatternParser are problematic since the
underlying implementation of PatternParser is radically different.
So I'm just skipping them for right now.
The remain big issue was the internal log messages polluting the log
files and causing the tests to fail. To address that I've been
working on some temporary fixes that move the log4j 1.3 behavior
close enough to 1.2's to allow the tests to pass.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
