: It's cool to know about the jul-log4j-bridge and I like the way with a
: single method call one can effectively short-circuit j.u.l. by stealing
: its output, but on very quick read it appears there is a potentially
: non-trivial performance penalty from the need to re-multiplex
: everything, and some of the limitations of j.u.l. remain in effect.
i haven't looked at the code for this jul-log4j-bridge, but if anyone
*really* wants to ridge the JDK / log4j gap once and for all there is a
fairly strait forward way to do it that can be as efficient as you want it
to be:
"Implement the JDK Logging API using classes that delegate to Log4J."
The only problems (in my humble opinion) with JDK logging are that:
1) it wsa branded poorly
2) it is both an API and a default implementation all rolled into one
without a well advertised seperation.
3) the default implementation supports only supports a very limited
config syntax.
The JDK logging docs are very clear about the fact that *ANYONE* can
extend the j.u.logging.LogManager class and make it behave anyway they
want -- the java.util.logging.manager system property can be used to pick
an implementation for your JVM at run time -- no one writting an
application *has* to use the j.u.logging.LogManager (or it's default
config file syntax) just because they use a library that uses
a j.u.logging.Logger.
I have never understood why Log4j doesn't provide some class like...
public JavaUtilLoggingManagerFacade extends java.util.logging.LogManager { ... }
-Hoss
