Emmanuel Bourg wrote:
Ceki Gulcu a écrit :
And everything ends in log4j, where redirecting JUL requires just one
line in your configuration.
How so?
http://people.apache.org/~psmith/logging.apache.org/sandbox/jul-log4j-bridge/examples.html
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.
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.
Have you already tested an application with Paul's bridge in production?
The same feature in logback would be nice (if it doesn't exist already).
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
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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
