[arquillian-issues] [JBoss JIRA] Issue Comment Edited: (ARQ-430) Decide on a common use of logging framework

[ https://issues.jboss.org/browse/ARQ-430?page=com.atlassian.jira.plugin.sy... ] Thomas Diesler edited comment on ARQ-430 at 4/28/11 9:06 AM: ------------------------------------------------------------- DML says JDK logging is nice in that there are no dependencies, and it is used by the JDK itself, as well as most things shipped by Sun. However it does have a number of bugs: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6487638 (fixed in recent JVMs) http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6274920 (fixed in 7+) Also some problems which we discovered: http://jira.jboss.com/jira/browse/JBAS-2087 There's more as well, these are just the ones I could dig up in a minute or two. The API is also fairly unwieldy; in particular, formatting and i18n is quite clunky, it doesn't perform very well (potentially a lot of lock contention) and the default log levels are unusual. Yes it is theoretically possible to replace the logmanager such that it forwards to another log framework. In practice this is pretty tricky and we still haven't managed to get it quite perfect, because the LogManager API itself is pretty bug-ridden and overall fairly craptastic. Another problem is that the JDK logging configuration system just sucks ass. The out-of-the-box options are pretty much terrible, and useless for most users. However, like log4j, slf4j, jboss-logging, and commons-logging, this is an API that people use, so we support it in the AS. The way we do it today is via JBoss LogManager, which is basically a complete replacement for the JDK logmanager which endeavors to fix the bugs, have performance that doesn't suck, introduce a real configuration mechanism, support our standard TRACE/DEBUG level system, and provide log4j-like handlers which are better than the built-in ones (not hard). As of AS 6, the forwarding works like this: (this won't look right with a proportional font!) {noformat} jcl-over-slf4j --> slf4j ---+ | log4j ---+----> JBoss LogManager | jboss-logging ---+ | JUL API calls ---+ {noformat} However wedging the logmanager in early enough at bootstrap is its own challenge, so it doesn't always work great for standalone processes. I have however successfully integrated logmanager into maven builds for test output without too much trouble. And there is a measurable performance improvement over either JDK logging or log4j, owing mainly to the modern concurrency techniques used. I think a good compromise is jboss-logging 3 - which not only gives you TAG-2/TAG-3 support but also imposes a minimal dependency (just itself). It will detect what logging framework is available and use it (first it tries JBoss LogManager, then log4j, then logback, then JDK logging). Also unlike the 2.x series, it's all self-contained in one JAR (in 2.x you needed the JAR for the backend you were interested in), and all the crap that isn't directly related to the job of being a logging API was stripped out (so it's a small JAR). Also it supports printf formatting which is really nice - it gets rid of a lot of the old "isTraceEnabled()" kind of stuff that one often has to do, because no formatting is done unless the message is loggable (a very fast check). Example: log.error(cause, "The %s thing blew up.", thing); log.trace("Received %s from %s", msg, address); Anyway, there's no perfect answer so my opinion on the subject changes over time. But for now, I think jboss-logging is a good bet. There is one feature still on the table which is to provide the *option* to let projects merge the jboss-logging JAR classes into their API, relocated under a different package, so there are essentially zero JAR deps. But this remains to be explored - hopefully it will just amount to a document explaining how to configure the Maven "shade" plugin, and/or whatever the ant/gradle equivalents might be. was (Author: thomas.diesler): DML says JDK logging is nice in that there are no dependencies, and it is used by the JDK itself, as well as most things shipped by Sun. However it does have a number of bugs: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6487638 (fixed in recent JVMs) http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6274920 (fixed in 7+) Also some problems which we discovered: http://jira.jboss.com/jira/browse/JBAS-2087 There's more as well, these are just the ones I could dig up in a minute or two. The API is also fairly unwieldy; in particular, formatting and i18n is quite clunky, it doesn't perform very well (potentially a lot of lock contention) and the default log levels are unusual. Yes it is theoretically possible to replace the logmanager such that it forwards to another log framework. In practice this is pretty tricky and we still haven't managed to get it quite perfect, because the LogManager API itself is pretty bug-ridden and overall fairly craptastic. Another problem is that the JDK logging configuration system just sucks ass. The out-of-the-box options are pretty much terrible, and useless for most users. However, like log4j, slf4j, jboss-logging, and commons-logging, this is an API that people use, so we support it in the AS. The way we do it today is via JBoss LogManager, which is basically a complete replacement for the JDK logmanager which endeavors to fix the bugs, have performance that doesn't suck, introduce a real configuration mechanism, support our standard TRACE/DEBUG level system, and provide log4j-like handlers which are better than the built-in ones (not hard). As of AS 6, the forwarding works like this: (this won't look right with a proportional font!) jcl-over-slf4j --> slf4j ---+ | log4j ---+----> JBoss LogManager | jboss-logging ---+ | JUL API calls ---+ However wedging the logmanager in early enough at bootstrap is its own challenge, so it doesn't always work great for standalone processes. I have however successfully integrated logmanager into maven builds for test output without too much trouble. And there is a measurable performance improvement over either JDK logging or log4j, owing mainly to the modern concurrency techniques used. I think a good compromise is jboss-logging 3 - which not only gives you TAG-2/TAG-3 support but also imposes a minimal dependency (just itself). It will detect what logging framework is available and use it (first it tries JBoss LogManager, then log4j, then logback, then JDK logging). Also unlike the 2.x series, it's all self-contained in one JAR (in 2.x you needed the JAR for the backend you were interested in), and all the crap that isn't directly related to the job of being a logging API was stripped out (so it's a small JAR). Also it supports printf formatting which is really nice - it gets rid of a lot of the old "isTraceEnabled()" kind of stuff that one often has to do, because no formatting is done unless the message is loggable (a very fast check). Example: log.error(cause, "The %s thing blew up.", thing); log.trace("Received %s from %s", msg, address); Anyway, there's no perfect answer so my opinion on the subject changes over time. But for now, I think jboss-logging is a good bet. There is one feature still on the table which is to provide the *option* to let projects merge the jboss-logging JAR classes into their API, relocated under a different package, so there are essentially zero JAR deps. But this remains to be explored - hopefully it will just amount to a document explaining how to configure the Maven "shade" plugin, and/or whatever the ant/gradle equivalents might be. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira