[jboss-dev] My logging ultimatum

[Sacha Labourey]

(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
>> _______________________________________________
>> 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