logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Kjome <h...@visi.com>
Subject Re: slf4j and log4j
Date Sun, 01 May 2005 03:09:15 GMT
At 06:16 PM 4/30/2005 -0700, you wrote:
 >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
 >I am not a member of the slf4j team, so I cannot speak to it's goals, etc.

I think just about any Log4j committer is part of the slf4j team, unless I 
am mistaken.  I'm guessing that this probably also extends to 
commons-logging developers.  In any case, I wouldn't characterize you as 
not being part of the slf4j team.  I think if you show a development or 
steering interest, you are probably part of the team.  Ceki, can you 
clarify this?  I think there is some ambiguity here.  How does one become a 
committer on the slf4j project?  Does one need to have commit access to be 
considered part of the slf4j project team?

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

Keep in mind that besides creating a more neutral place to avoid the 
appearance of a particular team dominating the project, the code was moved 
outside Apache in order to use a more compatible license.  The Apache 
license is not compatible with GPL and LGPL licenses.  If we are to develop 
a common logging interface for everyone's use, we shouldn't mean "everyone 
that is compatible with the Apache license", but simply "everyone".

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

yes, we can't have a bunch of incompatible releases floating around.  That 
would create a support nightmare for us and a dependency nightmare for users.

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

I think "consensus" is the key word.  If we don't get buy-in from lot of 
entities, slf4j will have been a noble, but failed effort.

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

This is a good idea, and it would allow us to hammer out whether 
implementing interfaces or treating slf4j as a facade is the best way to 
go.  There are more factors to think about than just 
performance.  Experimental releases would allow for some real-world testing 
of which idea is better.

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

See my answers above.  There are at least 2 clear and concise 
reasons.  There may be more, but the two I pointed out are enough to 
justify slf4j being an external project.



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

View raw message