The abstract method format changed signatures from String format(LoggingEvent event) in log4j 1.2 to format(Writer output, LoggingEvent event) in log4j 1.3 which means than any existing log4j 1.2 user supplied Layout will not longer compile and will likely result in a MethodNotFound if the new format method is called on a previous compiled. Also HTMLFormat appears to be missing from 1.3.
Added additional unit tests to 1.2 branch in revision 358758.
There are several issues that are addressed in rev 359667. 1. Change to signature of abstract format method in Layout: The signature of the abstract format method was changed from String format(LoggingEvent event) to void format(Writer output, LoggingEvent event) throws IOException and the original method was provided by delegating to the new method. While it would be good to redesign the class to have a Writer, StringBuilder or StringBuffer as a parameter in 2.0, the only appender that directly used the new signature was SyslogAppender and the Layout implementations had not been modified to eliminate use of their static StringBuffers. Basically, then only thing that had changed is they had an output.write(sbuf.toString()) at the end. Since the benefits of the changed signature had not been realized and the change would break user provided layouts, it seemed best to revert to the 1.2 signature. 2. HTMLLayout had been moved to org.apache.log4j.html This patch restores its previous package name. 3. o.a.l.helpers.DateLayout had been collapsed into o.a.l.TTCCLayout This patch restores DateLayout (from the current TTCCLayout code) which could have been used as a base class for user supplied layouts. Both DateLayout and TTCCLayout are marked as deprecated. The only remaining Layout related incompatibility is with the PatternLayout.createPatternParser which could have been overriden in derviatives of PatternLayout to introduce custom format specifiers. The implementation of PatternLayout in 1.3 appears to be so significantly changed that restoring that capability may be difficult. All recently added unit tests from the 1.2 branch were ported with only minor changes. The MyPatternParser and MyPatternLayout tests which use the lost PatternLayout.createPatternParser method were not ported.
In rev 384131, restored the PatternLayout.createPatternParser() extension point and classes org.apache.log4j.helper.PatternParser, PatternConverter and FormattingInfo needed to support user-provided custom PatternLayouts, but no longer used by "stock" log4j. When using the "stock" PatternLayout, an instance of org.apache.log4j.pattern.BridgePatternParser is returned by createPatternParser() which bridges between the old API and the new log4j 1.3 implementation (o.a.l.pattern.PatternParser) which adds new features like %logger and timezone specifiers. Custom PatternLayout's will have extended the otherwise unused o.a.l.helpers.PatternLayout and so will not transparently inherit the new log4j 1.3 features. See http://marc.theaimsgroup.com/?l=log4j-dev&m=113991484525345&w=2 for a report from the field from a user who observed the compatibility problem that was anticipated in the previous comment.
Just to confirm this fix works in real life, as well as in Junit tests. With the layout specified in a log4j.properties file.