[jboss-dev] My logging ultimatum

David M. Lloyd david.lloyd at redhat.com
Wed Dec 12 10:03:47 EST 2007 

On Wed, 12 Dec 2007 15:42:41 +0100
Adrian Brock <abrock at redhat.com> wrote:

> On Wed, 2007-12-12 at 08:27 -0600, David M. Lloyd wrote:
> > Well... honestly I don't know which bugs he's referring to.  
> 
> Here's one only fixed in Java7:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6487638

This one only applies to the default LogManager.

> Or this memory leak:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6274920

This one too...

> known about since 2003
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4811930

This one too...
 
> Here's one of our workaround's so it doesn't stop
> logging when you press ctrl-c
> http://jira.jboss.com/jira/browse/JBAS-2087

This one too.

> etc.
> 
> > But
> > providing a custom LogManager basically lets you provide a complete
> > replacement implementation for the Logger class if you want, so it
> > seems likely.
> > 
> > - DML
> > 
> > On Wed, 12 Dec 2007 15:19:09 +0100
> > Sacha Labourey <sacha.labourey at jboss.com> wrote:
> > 
> > > are you sure it is possible to provide an implementation of JUL that 
> > > work around the bugs mentioned by Adrian?
> > > 
> > > On 12/12/2007 03:04 PM, David M. Lloyd wrote:
> > > > 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
> > > > _______________________________________________
> > > > jboss-development mailing list
> > > > jboss-development at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/jboss-development
> > > _______________________________________________
> > > jboss-development mailing list
> > > jboss-development at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/jboss-development
> > _______________________________________________
> > jboss-development mailing list
> > jboss-development at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jboss-development

More information about the jboss-development mailing list