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 >comments. > >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.
Jake
>-Mark
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
