On 06/03/2010 4:29 PM, Joern Huxhorn wrote:
On 06.03.2010, at 14:48, Ceki Gülcü wrote:
Hello all,
Here are the 4 items I'd like to address in SLF4J 2.0:
1) Varargs for Logger methods http://bugzilla.slf4j.org/show_bug.cgi?id=31 Require JDK 1.5 and remain binary compatible as explained in my comment #31 dated 2009-03-25
2) logging exception if last argument, as exaplined by Joern in http://bugzilla.slf4j.org/show_bug.cgi?id=43
3) Avoid bogus incompatibility warnings http://bugzilla.slf4j.org/show_bug.cgi?id=154
4) fix http://bugzilla.slf4j.org/show_bug.cgi?id=170 possibly with a nop implementation of org.apache.log4j.NDC
Are there any other major items? Is everyone OK with requiring JDK 1.5 in SLF4J 2.0?
Hi Ceki,
While I'm a big fan of #31 and #43 and personally don't need <1.5 compatibility, I fear that dropping it might seriously hurt libraries using it right now.
That's the $64k question. If library lA depends on SLF4J and target JDK 1.4, nothing prevents lA from continuing to use SLF4J version 1.5.11. It gets a little trickier when library lB targets JDK 1.5 and depended on SLF4J v2 and if some application aX requires both lA and lB. Since SLF4J v2 is intended to be binary compatible with SLF4J 1.5.x, aX can use SLF4J v2 and lA will run just fine (without recompilation or anything). Where it gets really hairy is when an app server like Geronimo, JBoss or Spring DM bundle some version of SLF4J, say v1.5.11. If the end-user cannot freely chose the version of SLF4J (and this happens quite frequently) because the the app server imposes its version of SLF4J, then we might run into serious problems, unless SLF4J v2 and 1.5.x are binary compatible. As mentioned in comment #10 dated 2007-10-10 on bug 31, we can have binary compatibility as long as logger.trace|debug|info|warn|error(String, Object[]) logger.trace|debug|info|warn|error(Marker, String, Object[]) are changed to logger.trace|debug|info|warn|error(String, Object...) logger.trace|debug|info|warn|error(Marker, String, Object...) with all the other methods remaining unchanged. If the assumption about binary compatibility is wrong, SLF4J will probably not survive the shitstorm ensuing the release of v2.
I also guess that lots of people using SLF4J aren't following this mailinglist so this should probably also be discussed on slf4j-user@qos.ch . We'd still miss lots of users and I guess this will result in crying after the fact.
True. As Gunnar Wagenknecht observed, the BasicMDCAdapter class since it was introduced in early 2008, withing its remove() method invokes a method new to JDK 1.5. Thus, whenever the MDC.remove method is called under JDK 1.4, for any binding other than logback (which has its own MDCAdapter implementation and anyhow requires JDK 1.5) will cause an exception to be thrown. As far as I can remember no one has complained about this bug before Gunnar. So either no one is using org.slf4j.MDC#remove under JDK 1.4 or those who do, do not care enough to complain. Here is the link to BasicMDCAdapter dating from 2008-01-15: http://tinyurl.com/yherxp9 I find this BasicMDCAdapter.remove episode really puzzling. The only simple explanation I see is that few SLF4J users run under JDK 1.4 or more accurately the overlap of org.slf4j.MDC and JDK 1.4 use corresponds to a very small number of users.
It's a shame that there's no tool to analyze the whole central Maven2 repository concerning this, or is there? It would be great if there was a way to find out which modules depend on SLF4J (either directly or transitively) and are still 1.4.
Let's google it. :-)
If we'd consider my alternative suggestion in http://bugzilla.slf4j.org/show_bug.cgi?id=31 , i.e. http://github.com/huxi/slf4j/tree/slf4j-redesign , we'd stay binary compatible, keep JDK<1.5 support and would still support 1) and 2) - it's a win-win.
If we are going to re-implement org.slf4j.Logger under org.slf4j.n.Logger, we might as well call it org.newslf4j.Logger and start over from scratch. Copying the API to new packages avoids conflicts but otherwise constitutes a radical break.
Concerning 4), I've also implemented an NDC in my branch which uses the same Message (and, therefore, cheap, parameterized messages like SLF4J) as my suggested Logger interface. This means it's much more powerful than the log4j one (which expects one word per entry without enforcing it - I derive this from the way NDC is formatted in log4j xml) but log4j NDC can be implemented easily by wrapping it. It would only be available in the new SLF4J API - that was my plan, at least. In case of log4j-over-slf4j, we could use the new SLF4J NDC if available (i.e. in case of Java 1.5), falling back to an NOP implementation otherwise.
As I stated before, I'm a big fan of NDC and see it as a very good supplement to MDC. We actually use the NDC version available in Lilith in our production environment and it's quite helpful. I really don't understand why it was omitted from SLF4J. It's comparable to a manual, semantic stacktrace.
If you are used to log4j's NDC, having NDC in SLF4J is more comfortable than not having it. Otherwise, since MDC is semantically richer than NDC (one can trivially implement NDC over MDC), one can always get by using MDC instead of NDC. Another reason was that by scrapping NDC in SLF4J there was one less piece of code to maintain.
However this discussion ends, I'm really looking forward for SLF4J 2.0!
Cool.
Cheers, Joern.