Re: Log4j 1.3 Woes

[Jess Holle]

I ran a little static analyzer over the pile of 3rd-party libraries we happen to be using at the moment to search out known binary compatibilities issues with log4j 1.3 and existing libraries. Some findings: Usages of methods that will break binary compatibility. Class Referenced Method Referenced Used by org.apache.log4j.Category isEnabledFor(Priority) org.apache.avalon.framework.logger.Log4JLogger org.apache.log4j.Category isEnabledFor(Priority) org.apache.commons.logging.impl.Log4JLogger org.apache.log4j.Category log(String,Priority,Object,Throwable) org.apache.commons.logging.impl.Log4JLogger As I already discovered in our own code, it is not uncommon for "normal" (non-JCL or Avalon) code to directly use these isEnabledFor, log(Priority,Object) or log(Priority,Object,Throwable).  If such code followed the 1.3 compatibility guidelines then it will produce references to Logger in the first column, which is good.  Unfortunately: Such binaries will still be incompatible due to the Priority references embedded in the method signatures as per the second column. Rather current versions of binaries contain embedded references to the Category class -- rendering them binary incompatible. The Avalon version here is that bundled with and required by the latest version of Apache FOP. The commons logging version here is that bundled with Tomcat 5.5.9. The good news is that in our own (fairly extensive but not including any app server libraries) mix of 3rd-party libraries seems to be limited to issues in the "Used by" classes above plus org.apache.commons.logging.impl.Log4JCategoryLog. On the other hand, I think this means that Priority should be reintroduced to log4j 1.3 immediately.  I believe that either the same needs to be done for Category or the log4j developers need to find a way to fix Avalon and JCL so that they are source and binary compatible with both log4j 1.2 and 1.3 and get these changes in place immediately.  I think the safer and more prudent approach (since Avalon and JCL are not the end-all of deeper log4j usages) is to immediately re-instate Category as well. I believe the path to reintroducing these should actually be to create abstract deprecated Category and Priority classes that are Javadoc'ed to be historic and which have only package-access constructors.  Some abstract methods will clearly need to be declared on Category to preserve existing code.  Additionally the isEnabled() and log() methods noted above will need to be reintroduced.  The 1.3 compatibility recipe documentation should then be subsequently reworked. Remaining source and binary compatibility issues after these pale by comparison, so I'd really like to see these tackled right away. Is log4j using SVN or CVS at this point?  Is HEAD reasonably stable at the moment?  If so, I can tinker with this and propose diffs. -- Jess Holle