David M. Lloyd wrote:
This is my point - on the one hand you reject the only solution, and
on
the other, you refuse to use an otherwise good library because of the
problem. :-)
But my point is exactly this. JDK logging is two things. First, it's
a logging API - like commons-logging, but *built in*! Second, it's a
(pretty crappy) appender framework.
OK, sure, the handlers aren't that great. But guess what? The user
already has stuff using JDK logging just by virtue of using the JDK!
And just about every container supports JDK logging (well, except for
ours anyway).
Trust me, the user would rather deal with (just) JDK logging than
having 4 different logging JARs in their classpath.
Has anyone ever explored the possibility of getting the log4j people to
supply a JDK LogManager that maps JDK logging to log4j? That would
solve the non-container case. I may take a day this week to just write
one, or rather adapt the one I've already written.
The jboss-common-logging project has a JDK appender with essentially the
same feature set as log4j. I myself added support for MDC and NDC awhile
back. So any jboss project which uses jboss-common-logging, supports
both JDK and log4j logging.
--
Jason T. Greene
JBoss, a division of Red Hat