[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