[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