Hi!
> There are two pros of slf4j I did not mention yet:
> 1. parameterized messages, which make it possible to omit those ugly
> "if (logger.isDebugEnabled()) {..." conditions, without performance
>issue: see http://www.slf4j.org/faq.html#logging_performance
http://java.sun.com/j2se/1.5.0/docs/api/java/util/logging/Logger.html
Seems that JUL support this too if we use the log() methods.
I've looked at the java source. JUL is using MessageFormat.Format then in the
formatter only if there is a placeholder in the message ({0-{4).
Not that bad.
> 2. it's no longer possible to forget the log message by writing
> "logger.error(exc)" instead of "logger.error("an error has occured",
> exc)". This is because the slf4j api is strict and only allows a
> String (and not an Object) as first argument.
Funny, JUL also has no log(ex) method, just log(String, ex) (+ level for sure).
Seems the JUL API is not that bad :-)
> What I'm not sure is
> if the "JUL to other logging impl bridge" is multiple application
> friendly. What happens if the JUL root handler is replaced (thats what
> these bridges seem to do). Does this influence the servlet container
> logging and other apps as well?
Seems to be true, JUL is not container friendly by default. But this needs to
be addressed by the container (and the Java Spec guys ;-) ).
It seems, this is the reason for JULI, the Tomcat logging impl.
Also JBoss solved that (as they use Tomcat ?!). See for a documentation here:
http://www.jboss.org/file-access/default/members/jbossweb/freezone/docs/latest/logging.html
They replace the LogManager by a container friendly LogManager. The JUL using
app does not need to know that.
Yeah, seems JUL can be our salvation finally ;-)
Ciao,
Mario
