[slf4j-dev] Plan for SLF4J 2.0

Joern Huxhorn jhuxhorn at googlemail.com
Sat Mar 6 16:29:47 CET 2010


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.

I also guess that lots of people using SLF4J aren't following this  
mailinglist so this should probably also be discussed on slf4j-user at qos.ch 
  .
We'd still miss lots of users and I guess this will result in crying  
after the fact.

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.

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.

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.

However this discussion ends, I'm really looking forward for SLF4J 2.0!

Cheers,
Joern.


More information about the slf4j-dev mailing list