logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Endre Stølsvik <En...@Stolsvik.com>
Subject Re: slf4j and log4j
Date Tue, 03 May 2005 14:20:18 GMT
On Sun, 1 May 2005, Ceki Gülcü wrote:

|
| I don't want to be dismissive but these are just a bunch of excuses. Sure,
| the objections are all reasonable and all, but at the end of the day they
| boil down to excuses preventing forward movement.

Why don't you put the trace-level into the 1.2 branch, then??

Your excuses for NOT doing something that -clearly- lots of people want
(as demonstrated __multiple__ times on the different user lists), are -so
incredibly- more faint than those actual real and present problems that
Mark describes in his mail.

What's the goal of slf4j if you're not going to have a discussion and a
proper release of that project, before -hammering- the stuff into log4j ON
THE STABLE 1.2 BRANCH???? Is it all just a play so that you can tell folks
that they're lame, since they don't love your new
developed-in-an-open-fashion framework, that were released after two weeks
or so, w/o any "community feedback" at all? This is borderline ridiculous.

The JCL/log4j issues are taking too much time, time that would be better
spent on adding the trace level into the 1.2 branch and cutting a release!

 ( ;) )

|
| Fortunately, this is open source where we can take our marbles and play
| elsewhere.

Thank god. With your continued attitudes towards your own fellow
developers (e.g. that line above), not to mention denying user feedback
time after time (trace, for gods sake), someone probably will do that with
log4j itself RSN.

Or someone already have?

http://home.comcast.net/~pdegregorio/trace4j/trace4j-how-to.htm


|
| At 03:16 5/1/2005, Mark Womack 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
| >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
|
|

-- 
Endre Stølsvik -  Endre@CoreTrek.com
   Phone[+47 23308080] Mobile[+47 93054050] Fax[+47 23308099]


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