[jboss-dev] My logging ultimatum

Wed Dec 12 11:15:42 EST 2007

While we work of coaxing all OSS projects that JBoss is concerned with, 
to use JDK logging, can we also work on Global Warming and Ending World 
Hunger. This is because we can get it done in the same time frame. :)

Pray, tell me about JDK logging configuration.  If I want to introduce 
xml based configuration instead of the default properties file based 
setup, do I need a plugin?

Tim Fox wrote:
> +100 to David on this.
>
> The point here is about reducing number of dependencies. Another 
> meta-framework (like jboss common logging) is not a good solution 
> IMHO. This is particular important for OEMs who may want to use our 
> project embedded in their own applications (this is what we intend to 
> do for JBM2)
>
> If JDK logging can allow you to delegate to you log tool of choice by 
> deploy time configuration, and the bugs in JDK logging are only bugs 
> in the JDK logging implementation which you can bypass anyway, then we 
> should all be using JDK logging surely.
>
> I'm certainly going to look at refactoring JBM to use JDK logging.
>
> David M. Lloyd wrote:
>> 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