[jboss-dev] My logging ultimatum

[Adrian Brock]

Why do we keep having this thread over and over again
with ever new developer?

1) Use the jboss logger

JBoss has a very simple wrapper, as Jason and Scott explained.

The logic is
if (system property set)
   use implementation of system property
else if (log4j in classpath)
   use log4j
else
   don't log

Advantages:
* You can choose log4j, jdk logging or implement a wrapper
to your own logging framework
* You can choose not to log at all, e.g. in a client
where you don't control the logging configuration at all
* It is very small

$ du -h jboss-common-logging-spi-2.0.5-SNAPSHOT.jar 
16K     jboss-common-logging-spi-2.0.5-SNAPSHOT.jar

2) There are many thirdparty components using different logging
frameworks. Even things like Hibernate and JGroups use clogging.

Unless we are going to fork them to fix the logging
we're always going to have to deal with many logging frameworks.
(Most of them are from Apache - let a thousand WEEDS bloom :-)

3) JDK logging is broken/useless

There are many bugs in the JDK logging that lead to deadlocks,
memory leaks or just broken behaviour, we have workarounds
for some of them (as usual a spec written for JavaSE
doesn't anticipate the needs of JavaEE :-)
And as has been already said, there are no useful appenders.
Maybe with JDK7 we can fix/mitigate these problems?

I'm sure this thread will appear again in 6 months when
the next new developer joins the project. 
Logging always seems to be one of those flamebait topics,
I don't see why, it really isn't that interesting. :-)

On Wed, 2007-12-12 at 00:01 -0600, David M. Lloyd wrote:
> What's the motivation behind this?  Just dropping log4j?  It seems to
> me that we'd want to provide some way for the tons of crap still using
> log4j to still log to the log file properly.
> 
> - DML
-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx