logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Womack <wom...@adobe.com>
Subject RE: slf4j and log4j
Date Mon, 02 May 2005 18:22:20 GMT

> -----Original Message-----
> From: Simon Kitching [mailto:skitching@apache.org]
> Sent: Saturday, April 30, 2005 7:41 PM
> To: Log4J Developers List
> Subject: Re: slf4j and log4j
> >
> > 2) There is demonstrated consensus from the slf4j organization.  I want
> some
> > understanding that their (future) release version attains whatever goals
> > they have set and that they do not expect it to change significantly in
> the
> > future.  If this was an effort within Apache, trying to achieve a common
> > interface/api, I would have the same requirements (though I think it
> would
> > be easier, quite frankly).  I use the word "consensus" because I expect
> > there to be a group of developers deciding the slf4j fate.
> Unfortunately, building a community of developers is easier when there
> is a released product available!
> But yes I think a release is also a little too early. SLF4J developers
> may wish to review the enormous volume of emails re "enterprise logging
> for JCL" that occurred on the jakarta-commons-dev list about 3 months
> ago. This debate (mostly originating from Richard Sitze) was about
> enhancing the JCL API to perform i18n along with other issues. This
> discussion is probably equally relevant to the SLF4J API. [NB: no
> conclusion was reached during this debate and discussion eventually
> trailed off without action].

There is nothing wrong with breaking the slf4j stuff into different "domain"
interfaces.  If all I want as a developer is simplified, cross-logging
framework api and I don't care about the enterprise aspects, why should I be
forced to use the most complicated enterprise api?  The 1.0 version of slf4j
could be the simpler api (modified to accept analysis from the JCL team,
whatever comes of that or other considerations).  A later 1.X or 2.0 version
could include the more complicated enterprise interface definitions (or
whatever the slf4j team deems required/worthy).  The log4j team could choose
to implement that new version or not, but it could still support the 1.0
api.  Some industrious soul could still create their own implementation of
the updated api based on log4j if they wanted.


To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message