commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gulcu <c...@qos.ch>
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
proposing?

>> 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 http://www.slf4j.org/legacy.html
> 
> 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.
http://logback.qos.ch

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message