[jboss-dev] My logging ultimatum

[David M. Lloyd]

On Wed, 12 Dec 2007 12:31:52 +0100
Adrian Brock <abrock at redhat.com> wrote:

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

Because you're wrong? ;-)  J/K, but read on.

> 1) Use the jboss logger
> 
> JBoss has a very simple wrapper, as Jason and Scott explained.

Great.  Now my project requires the jboss wrapper.  But my project's
two dependencies require slf4j and log4j, making three different JARs
in total, just for logging. Problem solved!

> 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

This choice is purely illusion.  It seems like I have such a choice,
but the reality is that I'm locked in to requiring a dependency -
the jboss-common-logging jar.  How is this better than using slf4j?

On the other hand, if I use JUL then the problem is reduced - now the
user need only include slf4j and log4j JARs.  I think I've convinced
Clebert to switch to JUL for jboss-serialization (though I bet he'll
want to see what the outcome of this discussion is first), so that would
get rid of the log4j - then it's just down to slf4j in MINA, which I'm
currently lobbying on their mailing list.  If I succeed in my efforts,
the user will have *no* external logging JARs needed for MINA, JBoss
Serialization, *or* Remoting.

> * 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

This is good for things running within the container, but in the
standalone case it's no different (to the user) than if I required
commons-logging or slf4j myself.  Except that nobody else on the planet
(well, outside of JBoss) would ever depend on jboss-common-logging.

The fact is, zero JARs is better than one, no matter how small it is.

> 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 :-)

Gotta start somewhere.  If I can convince MINA, perhaps other Apache
projects will also see reason. :-)

Just because few people hold this viewpoint today doesn't mean that
more won't tomorrow.

> 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?

Waiting for JDK7 to fix anything is... well, let's not do that.  I'm
with Trustin on this - let's do a JBoss.org project for adding support
to JDK logging to make it useful.  A LogManager to delegate to popular
logging frameworks would be a great start - as would a collection of
useful appenders.  This basically makes JDK logging into a built-in
commons-logging of sorts - it becomes the user's choice what logging
backend to use.

It would be my hope that the log4j/logback/etc of the world would
integrate code to provide a LogManager of their own that would
intercept JDK logging and handle it properly.  I think if we initiate
this effort, they will follow.

In any case, by using JDK logging in these middle pieces, the user
can just include JARs for the logging backend/API that they like.  This
is the real crux of the whole issue.

> I'm sure this thread will appear again in 6 months when
> the next new developer joins the project. 

When they run into the same problem and get frustrated by the lack of a
good solution?  Sure.

> Logging always seems to be one of those flamebait topics,
> I don't see why, it really isn't that interesting. :-)

If "interesting" were the only criteria...

- DML