[slf4j-dev] [Bug 116] Switching the log message format to that of java.util.Formatter

bugzilla-daemon at pixie.qos.ch bugzilla-daemon at pixie.qos.ch
Fri Nov 28 19:50:52 CET 2008


http://bugzilla.slf4j.org/show_bug.cgi?id=116





--- Comment #10 from Grzegorz Borkowski <grzegorzborkowski at o2.pl>  2008-11-28 19:50:51 ---
I'm not sure if I have time to try to experiment with it and do performance
statistics. But when I have a free time, I will try to do it.

Regarding logging JSR:
For me, easy to use and efficient logging API should be at the core of any
platform such as Java, because it is needed for virtually any application:
desktop, web, any. It's strange it was not since Java 1.0, only from 1.4. 
However, 1.4 JUL was broken from the beginning, and will never gain popularity
because of its limitations. So either it will be fixed (what perhaps means
quite significant reimplementation) or replaced by something better. Current
situation is a chaos: some libraries use JUL, other Log4j, other
commons-logging, etc. Nobody knows how to configure this mixture to work
seamlessly on web servers like Tomcat (from my experience adding any logging
library dependency to the project always introduced strange memory leaks on
Tomcat, in whichever configuration). I believe not only I'm tired with this
situation, but other people too. If we have the really good JRE-API for
logging, this would solve many people's problems.
>From my perspective, such API should meet following requirements:
- parametrized logging (everybody hates the "isDebugEnabled" bloat in the code) 
- simple logging stack traces at least for error level: logger.error(message,
Throwable)
- MDC 
- RotatingFile appender with flexible rotation triggering
- simple but efficient configuration in the XML or properties file, which can
be shipped with application
- ability to configure individually each application running in managed
environment, as well as environemnt itself.
Additional features, like not-so-popular appenders (JMS,SMTP) could be left for
third-party libraries implementations, but using common API, and using common
configuration.
I think those are common requirements, and most of the developers would agree
with them. Unfortunatelly, JUL doesn't meet any of them. On the other hand,
SLF4J+Logback seems to fit to it quite nicely. This is why I think it is a good
candidate to replace JUL (or be a ground for JUL reimplementation). 
I agree this it is a bit controversial, but 90% of Java developers probably
would agree with my point.


-- 
Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the slf4j-dev mailing list