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

Thu Apr 28 09:06:18 EDT 2011

    [ https://issues.jboss.org/browse/ARQ-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598751#comment-12598751 ] 

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. 

> Decide on a common use of logging framework
> -------------------------------------------
>
>                 Key: ARQ-430
>                 URL: https://issues.jboss.org/browse/ARQ-430
>             Project: Arquillian
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Thomas Diesler
>             Fix For: 1.0.0.Beta1
>
>
> I suggest to 
>         <version.jboss_logging>3.0.0.Beta4</version.jboss_logging>
>         <version.jboss_logmanager>1.2.0.CR8</version.jboss_logmanager>
>             <dependency>
>               <groupId>org.jboss.logging</groupId>
>               <artifactId>jboss-logging</artifactId>
>               <version>${version.jboss_logging}</version>
>             </dependency>
>             <dependency>
>                 <groupId>org.jboss.logmanager</groupId>
>                 <artifactId>jboss-logmanager</artifactId>
>                 <version>${version.jboss_logmanager}</version>
>             </dependency>
> in core build/pom.xml
> All dependent modules can use the same logging framework as AS7 by default 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira