logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <skitch...@apache.org>
Subject Re: slf4j and log4j
Date Sun, 01 May 2005 02:40:58 GMT
On Sat, 2005-04-30 at 18:16 -0700, Mark Womack wrote:
> Even though slf4j inherits everything from the former log4j UGLI interfaces, 
> it seems to me that part of its reason for existence is to foster some 
> common, neutral area where the members of the Logging Services team, the JCL 
> team, and others can work out whatever issues they felt they could not work 
> out within the walls of Apache.  As such, I expect that there are going to 
> be some number of changes to the base slf4j framework.  Looking at the slf4j 
> list archives, those discussions have yet to really kick into gear.  As Curt 
> pointed out, slf4j has only existed as an entity for a couple of weeks.

I don't think the existence of SLF4J vs UGLI is likely to make any
significant difference to the JCL/Log4J issues. The issue is whether
this approach meets the JCL requirements (which is still being
analysed), rather than what it is called, where it is hosted, or what
license is applied to it. [nb: my personal opinion only!]

I believe it *will* make it easier for *non-apache* projects to use this
API. Projects licenced any kind of license can embed calls to SLF4J
because SLF4J is licensed BSD-style. Having such projects contain
compile-time bindings to Apache-licensed code (be it log4j, UGLI or JCL)
may be less legally certain. Of course at runtime the library that ends
up being invoked may be log4j from Apache if the deployer has chosen
so...

I believe it is also intended to show that SLF4J is not "favouring"
log4j, and that other logging libraries are free to implement the SLF4J
interfaces if they wish. Having UGLI hosted within the log4j (or even
the apache-logging) site & source code repository didn't make this
clear. I'm not sure whether this is really a significant issue in
practice, though. As far as I know, the world has pretty much settled on
two logging libraries: log4j and JDK14-logging.

Note that, as far as I am aware, it is quite possible for UGLI and SLF4J
to be supported concurrently. I don't know whether this is the case or
not with this recent "release".


> Given that, I don't think that the log4j project should provide an official 
> implementation of the slf4j interface until:
> 
> 1) There is an official release from the slf4j organization.  Basing our 
> official releases on a single slf4j beta release version is not good.

Well, it might be ok as long as those classes are clearly marked
"experimental" or somesuch. Maybe mark them "deprecated" initially??

The xerces team had much the same issue re releasing previews of the
DOM3 apis....

> 
> 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].

> 
> So, while I don't think we should allow an official release of either log4j 
> 1.2.X or 1.3 with slf4j changes until the criteria above are met, I do think 
> that providing some kind of slf4j log4j implementation based on the current 
> slf4j api would be fine.  It should be a separate release from either of the 
> log4j releases and it would be appropriately labeled as "experimental" or 
> whatever we want to call it.  There would be an understanding that we 
> (log4j) support the slf4j effort and we are working with slf4j to provide an 
> implementation, but that the work is in progress.  The work could be done on 
> it's own branch.  We can wrangle through the details of implementation 
> directly or an efficient facade.  I still want to understand what slf4j 
> means to the JCL.

Also sounds reasonable to me.

> 
> I support the slf4j effort, especially if it solves the issues we have seen 
> related to JCL.  Rushing an implementation of it, even though based on the 
> UGLI code that we know and love(d), is not right.  Now it is with a group 
> that is outside of ours, in what appears to be a exploratory mode, we have 
> to take some care in that implementing it affects our log4j api.  Even once 
> we release an official version, whatever form it takes, if there are changes 
> to the slf4j api, it should be treated as any other supported log4j feature. 
> I certainly would not want to start doing many mini-releases of log4j around 
> api tweak changes in slf4j.  That is why I want some assurance that the 
> slf4j is "baked".

+1

Cheers,

Simon


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


Mime
View raw message