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? -Mark > -----Original Message----- > From: Ceki G�lc� [mailto:[EMAIL PROTECTED] > Sent: Friday, May 20, 2005 5:40 AM > To: Log4J Developers List > Subject: Re: [VOTE] slf4j support in log4j 1.2.X > > I think there is some confusion about the goals of SLF4J. First, SLF4J > is not about killing JCL. JCL answers a need by some users who wish to > be able to switch implementations if the need arises. JCL's current > implementation was driven by another less well known goal related to > isolation of logging environments in web-apps. JCL's dynamic > discovery mechanism provides a solution to both problems > simultaneously. > > JCL is non-intrusive in the sense that it wraps logging > implementations which do not need to know that they are being wrapped > by JCL. In contrast, SLF4J is designed with the needs of a logging > framework fist and users' needs second. This inverted set of > priorities may paradoxically result in better user satisfaction. The > point being that SLF4J is intended to be implemented *directly* by the > logging frameworks which decide to use it even if SLF4J can also wrap > a logging framework, but with lesser results. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
