Log4j 1.3 and 1.2 Binary Incompatibility

[Jess Holle]

Okay, I've read all the back threads Curt noted.... I must strongly disagree with the notion that log4j 1.3 should invert the class hierarchy between Logger/Category and Level/Priority in log4j 1.3. This completely breaks binary compatibility with 100% 1.3 compatible sources compiled against 1.2 and run against 1.3.  [In my case it broke this compatibility simply through use of sanctioned Logger methods and Level.WARN.] There's a lot of important value-add stuff in log4j 1.3, e.g. a better locking strategy for starters.  These changes which introduce binary incompatibilities add no significant value and present a major stumbling block to anyone using 1.3 in the forseeable future.  Indeed they appear to be solely a Quixotic quest for ivory-tower code purity.  [I understand that the developers would like to see Priority and Category go away or be renamed, but they wouldn't really bother anyone else that much assuming the Javadoc makes clear their legacy nature.] After the patch I just submitted with bug #37735, binary compatibility for "common" log4j usage should be pretty good at the moment.  This patch makes Priority the parent of Level once again *but* moves things around between Priority and Level in a sane way to balance cleanliness and binary compatibility. This is also assuming that: Category is not removed. Current JCL, Avalon, etc, releases use it. There is no harm in keeping it. The Category/Logger hierarchy is not inverted as originally proposed. Trying to remove it or invert the class hiearchy here as originally proposed will only produce more unnecessary binary compatibility issues. I'd thus like to see the patch applied and this whole Category vs. Logger and Priority vs. Level thing taken off the table so log4j 1.3 can move on to meaningful improvements. One of the strongest reasons not to chase the changes as proposed is that log4j 1.2 and 1.3 cannot co-exist in the same classloader yet it will be quite common to have existing libraries that are utterly dependent on each in the same classloader if the current path is followed.  In this case, please call it log4j 2.0 and place the entire set of classes under org.apache.log4j2. Note that I'm not saying effort should be spent ensuring that code blithely written against Category and Priority continues to work.  Rather as must code written against Logger and Level and compiled against log4j 1.2.x should continue to work in log4j as possible.  Also, let's keep avoid breaking the current *existing* versions of libraries that use log4j wherever reasonably possible -- including JCL and Apache FOP (which, unfortunately, uses Avalon). Let's stop the code-purity madness, preserve binary compatibility of existing common libraries and end-user code usages, and move on to produce better, faster, and more flexible logging! -- Jess Holle