commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Kolinko <>
Subject Re: [logging] logging vs slf4j
Date Sun, 07 Aug 2011 15:02:24 GMT
2011/8/7 Mark Thomas <>:
> On 07/08/2011 09:31, Jochen Wiedmann wrote:
>> On Wed, Aug 3, 2011 at 3:02 PM, Gary Gregory <> wrote:
>>> Or maybe Log4j 2 could replace [logging].
>> If we really have to reconsider this stuff, then I'd propose to
>> a) Use java.util.logging, because it doesn't require any additional
>> dependencies and is guaranteed to work anywhere.
>> b) Carefully document how to bridge jul to log4j, because that's
>> exactly what's required in almost any application container I am aware
>> of. (The exception being Tomcat, which uses jul anyways.)
>> c) If the slf4j fans insist, add similar documentation for bridging
>> jul to slf4j.
> +1. I like this plan.
> As an aside, Tomcat doesn't use jul, it uses JULI which is a modified
> commons logging implementation hard coded to output to jul by default
> with an alternative Jar that is hard-coded for log4j. Why the
> complexity? jul is not class loader aware which is a problem as soon as
> web applications start declaring loggers with the same name.
> Mark

Regarding Tomcat,

I want to correct Mark. Tomcat JULI != commons-logging. It is just
that two components are packed in the same jar. (E.g. in Tomcat 5.5
they were separate).

Tomcat logging (the "bin/tomcat-juli.jar:" file) contains the following:

1. Tomcat JULI which are additional components to java.util.logging.
There are two main components:
a) a custom implementation of java.util.logging.LogManager  that is
classloader-aware, allows to have separate logging configuration per
webapp, and also to have more rich configurations than the default
b) a custom FileHandler, that is better suited to our needs than the
standard one.

Tomcat JULI is enabled by setting certain java properties on the command line.

2. A copy of commons-logging renamed to a different package to avoid
conflicts with webapp-provided copies of the library.

The "tomcat-juli.jar:" can come in two flavors.
Default one: The default one uses stripped down copy of
commons-logging that has its discovery process removed and is
hardcoded to use java.util.logging.
Extras one: This includes full copy of commons-logging.  It is *not*
hard-coded for log4j.  It is just that its discovery process is kept
intact, so it can choose whatever logging framework it finds.

Best regards,
Konstantin Kolinko

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message