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" />
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.
Have you already tested an application with Paul's bridge in production?
No, JUL is good enough for my needs.
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.
Emmanuel Bourg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
