On Fri, 2005-05-20 at 10:39 -0700, Mark Womack wrote: > I need to look at this more myself. I just want a common logging client > interface that I can use in my code and when I do my deployments that client > interface will use whatever underlying logging framework is specified. > > I don't want any complicated discovery mechanism. I don't want the client > interface implementation to assume anything about my deployment around > isolation, or help with it in any way. All of that is just very specific to > the framework and/or web container. > > I just want to be able to say "use log4j" or "use jdk 1.4 logging" or use > "X" as the underlying logging framework without having to change my client > code; whatever I want to use for the deployment that makes sense for that > deployment. I'll set up the environment so that it makes sense (ie what > jars are deployed where, isolation at the container level using features > from the logging framework or child-first class loading of web applications, > etc). > > Maybe I am just ignorant in the details (a good possibility), but that is > what I want. Is slf4j going to provide that for me? If not, what is it > providing then?
Unfortunately, java container environments are not simple things. Asking for a simple answer to logging is like asking for a simple answer to world peace. I think the static binding approach as currently implemented by SLF4J (and previously UGLI) is the simplest possible answer to the problem of writing logging-lib-independent code that can be told to use a specific concrete logging library by the code deployer. Even then, things are not going to be trivial. For example someone recently had a problem with commons-logging; they were running code within webapp within a j2ee container via Ant from within Eclipse. That's at least 4 layers of classloaders there; sorting out which classes bind to which other classes is always going to be complicated. The disadvantage with the pure static binding approach of SLF4J is that there are some things that are impossible to do, like having code in a shared classloader log via a logging library present in a child classloader. However after much thought I have come to the conclusions that the static binding approach will satisfy 90% of cases. And that it can be extended, by statically binding to a factory that does dynamic lookup, to handle the other cases. And while jakarta-commons-logging (JCL) currently handles certain complex cases ok, I believe we can modify it to be able to use the SLF4J static binding for the simpler cases. So in effect, SLF4J and JCL could end up with the same architecture by approaching the problem from different ends. To go back to your original mail: you clearly want logging library independence, so direct log4j access isn't a solution. So you need a wrapper - and as far as I know, that's either SLF4J or JCL. SLF4J is simple, fast, but inflexible in certain situations. JCL is large, slow, and can be complex to deploy correctly, but handles certain tricky cases that SLF4J doesn't. So take your pick. Or you could invent your own better solution. While you're at it, could you come up with an answer for World Peace too? :-) Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
