logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Womack <wom...@adobe.com>
Subject slf4j goals (was: RE: [VOTE] slf4j support in log4j 1.2.X)
Date Fri, 20 May 2005 17:39:28 GMT
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,

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?


> -----Original Message-----
> From: Ceki Gülcü [mailto:listid@qos.ch]
> 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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message