[jboss-dev-forums] [Design the new POJO MicroContainer] - Re: java.util.logging Bridge Component
david.lloyd@jboss.com
do-not-reply at jboss.com
Tue Nov 11 16:44:10 EST 2008
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#4188609
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188609
More information about the jboss-dev-forums
mailing list