Re: Log4j 1.3 Woes

[Jess Holle]

Another binary compatibility issue: The 1.3 introduction of put(String,String) in MDC produces a binary that is incompatible with any log4j 1.2.x whenever the compiler knows the type of the second argument to be String (which is usually the case). This can, of course, be avoided by casting such Strings to Object, but overall this is just another hurdle between 1.2 and 1.3 for ever so little benefit.  Adding a "setProperty" or "putString" method instead akin to java.util.Properties would allow new code to use a safer API without hurting binary compatibility of recompiled legacy sources. -- Jess Holle Jess Holle wrote: Jess Holle wrote: P.S. As log4j 1.3 now stands, I'd think it would be tempting to repackage all of log4j 1.3 in org.apache.log4j2.* and call it log4j 2.0.  That way you could have log4j 1.2 and 1.3/2.0 in the same classloader at the same time without having to worry about some legacy library that requires 1.2.x and some other than requires 1.3.x.  As it stands now I worry about such issues cropping up more often than not. That's ugly, yes, but 1.3 seems to go out of its way to break both binary and source compatibility -- in which case using the same fully qualified package names is a bad thing! Jess Holle wrote: I just about a day and a half trying to get my code to be log4j 1.3 compatible while still being log4j 1.2.12+ compatible.  Note this was despite the fact that I reviewed the 1.3 compatibility guidelines prior to writing any of this code.  I clearly stepped over the lines in various areas, but there were non-trivial reasons for this. I have to say I am shocked by the lack of compatibility between the two.  I understand the need to clean things up, but there were a lot of gratuitous incompatibilities. Worst of all, despite all my efforts and the fact that my code now compiles just fine against 1.2.12+ and 1.3 alpha 7, I cannot compile against 1.2 and run with 1.3 (or presumably vice versa).  This turns out to be due to the fact that Logger has the following methods in log4j 1.2: isEnabledFor(Priority) log(Priority,Object) log(Priority,Object,Throwable) whereas in log4j 1.3 there are only equivalents of this that take "Level" instead of Priority.  The only alternative here appears to be to introduce some reflection-based utility, but that would defeat the speed and efficiency of these calls whose performance is absolutely critical! For this issue I would really like to see log4j 1.2.13 introduce: isEnabledFor(Level) log(Level,Object) log(Level,Object,Throwable) Also give that most legacy libraries won't be recompiled against a hypothetical 1.2.13 real soon, there is still something to be said for either: Reintroducing Category and Priority Sure their existence is ugly but how much did they *really* hurt anyone? Repackaing log4j 1.3 under org.apache.log4j2.* -- Jess Holle