Ah, nice.
On the conflict problem - surely having proper classloader isolation will mitigate that a
lot? I mean if we do this right then it won't matter whether the backend framework is
log4j or j.u.l or some other thing. I guess the following points would be most
important:
1) Apps and components which use any of JUL, log4j, clogging, slf4j, etc should all have
their output going to the same log system in the end
1a) log4j emulation API? (#3 above)
2) Whatever framework we use (if it is other than JUL) should be hidden (classloader-wise)
from the application
3) We should support old log4j.xml deployments (#2 above)
4) It would save a lot of work if we could provide a way to use log4j formatters and
appenders in any case (also #2 above)
From the perspective of #1/1a and #2, I don't think it matters at
all (to the user) what framework we ultimately choose. I just think it's important to
remember that there are two aspects of a logging framework - the backend logger structure
and the user logging API. And every project on the planet is likely to use a different
user logging API, so we should be prepared to accommodate that. We just need to make sure
that our backend logger supports everything the users want (formats, appenders, filtering,
so-called MDC, i18n, etc).
I just hate that feeling of rewriting something that already works. :-)
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188609#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...