[jboss-dev] My logging ultimatum

[David M. Lloyd]

On Wed, 12 Dec 2007 09:04:11 -0600
Anil Saldhana <Anil.Saldhana at redhat.com> wrote:

> The real problem is that VM vendors (JSR-47), rather than provide a 
> mechanism to plugin logging frameworks like log4j, took a detour and 
> provided us a "FINE, FINER, FINEST" mess. I do not see the folks behind 
> log4j on the expert committee of the JSR.

Yes, but providing custom log levels is trivial.  I do this to get back
DEBUG, TRACE, etc.

> The only argument that David is providing is that an user has to have 
> multiple jars just for logging.  Most of our projects have many jars 
> (oswego,Commons Logging,xb,common etc etc) as dependencies. Only JBAS 
> provides a common ground to develop applications anymore. :)

This is true.  But you can't blame me for trying to minimize the mess.

> Projects like OpenSAML2 have started to use slf4j.  If we are going to 
> integrate OSS projects, we have to provide support for their logging 
> choices.  JBoss Logging provides the best abstraction at the moment.

Sure, but we could also try influencing their choices as well.  SLF4J
is solving the same problem as JBoss logging, and clogging for that
matter.  If everyone (or even the majority of projects) in the OSS world
were using one or the other (including us) then I'd have no problem
advocating that.  But I don't see that happening - the only chance
there is for everyone to standardize on one logging API is to use the
one logging API that everyone is guaranteed to already have.

But none of that really matters in the big picture - we as a container
vendor should always have a LogManager installed anyway, because it's
not unreasonable for a developer to expect the standard logging
framework to function correctly -regardless- of our chosen logging
backend. I know I did when I first started using JBossAS.

And if we're already going to have a LogManager installed, then why not
just use JDK logging in our framework JARs?

- DML

> Sacha Labourey wrote:
> > (and he seems to disagree ;) )
> >
> > Let the fight continue! :)
> >
> > On 12/12/2007 03:27 PM, David M. Lloyd wrote:
> >> Well... honestly I don't know which bugs he's referring to.  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