logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Womack" <mwom...@apache.org>
Subject slf4j and log4j
Date Sun, 01 May 2005 01:16:13 GMT
This is a spinoff of the discussion regarding slf4j and log4j.  I reviewed 
Curt's email on the 1.2 branch changes, and I am building on some of his 
comments.

I am not a member of the slf4j team, so I cannot speak to it's goals, etc. 
As a log4j committer I have no opposition to it being directly 
implemented/supported in the log4j classes, however, I think that doing that 
implementation in the log4j 1.2 branch at this point is premature.

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.

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.

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.

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.

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

I say "slf4j organization", but it is just wierd since everyone in that 
"organization" is from log4j, and I suppose the JCL team(though I could not 
find a list of committers for slf4j).  It is still unclear to me exactly why 
folks felt it had to move outside of Apache, but that is a different 
discussion, and we are where we are.

-Mark 



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