commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gulcu <>
Subject Re: [Configuration] experimental branch uses java.util.logging?
Date Thu, 18 Jun 2009 17:56:27 GMT

Emmanuel Bourg wrote:
> Ceki Gulcu a écrit :
>> Redirecting to jul from log4j assumes that you have log4j.jar on your
>> class path. When you direct from jul to log4j, which is the case you
>> mentioned, then you need log4j.jar plus the bridge code which is
>> located in a different artifact (apache-jul-log4j-bridge). Thus, in
>> addition to apache-jul-log4j-bridge on your class path, you would also
>> need to invoke "JULLog4jBridge.assimilate()" in java (compiled) code,
>> not as a log4j configuration directive.
> You can also assimilate by adding this line to the log4j configuration:
>   <plugin name="julreceiver" class="org.apache.log4j.jul.JULReceiver" />

True. My bad.

>> There is also the overhead of converting each jul event to log4j
>> within the bridge. This overhead can be quite significant. In a
>> production system, you also have to synchronize the level of jul
>> logging with that of log4j. It's feasible but just more additional
>> work.
> The overhead is acceptable for the limited logging requirements of 
> Commons Configuration.

Indeed, if commons configuration does little logging, then you could
use jul and not worry about performance. However, using jul in the way
you describe is non-idiomatic. I don't think jul to log4j bridging is
a viable option in a large application with lots of active logging.

You seem to be focused on reducing the number of dependencies to a
strict minimum. However, in doing so, you might be making life harder
for your users.

>> Have you already tested an application with Paul's bridge in production?
> No, JUL is good enough for my needs.

Are you sure that commons logging and SLF4J do not make sense in the
post-Java 1.4 world if you have not tested the alternative you are

>> Logback is a native implementation of the SLF4J API. Among other
>> things, this means that logback is accessed via SLF4J. In other words,
>> if you are using logback, then you are using SLF4J. It also follows
>> that the job of of consolidating various logging frameworks is assumed
>> by SLF4J, not logback. See
> SLF4JBridgeHandler seems to do the job. A kind of plugin to enable it 
> from the logback configuration would be nice.

Duly noted.

> Emmanuel Bourg

Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.

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

View raw message