Sorry for the tardiness of my reply. I have been pulling some long hours at work and did not want to send a shoddy reply.
> I hear you. Now, bear in mind that log4j is competing against JDK 1.4 > logging which offers similar functionality, at least at the surface. > We can take pride in having influenced JDK 1.4 to the extend where it > just looks like a pale copy of log4j. Actually, I keep this fact in mind almost everyday with almost everything I do with log4j. The "threat" of jdk 1.4 logging is not that it provides a feature set similar to log4j. The threat is that it becomes the "easy" choice to use because it is embedded in the environment and it is "good enough". Log4j needs to provide compelling reasons and features to be a more useful alternative to jdk 1.4 logging. I believe that today's log4j core already provides this. But all of my thinking and activity has been central to the idea that more can be done at the "usability/tool" level to convince developers that log4j is the tool they should be using. My bent towards trying to "make existing functionality more useful" really struck me while I was creating the wiki page for the 1.3 features. Log4j is in a stronger position than jdk 1.4 logging in that there is a strong user base. There are people that want to make it a better package. I doubt Sun has many people dedicated to working on their logging package right now. I haven't looked very hard, but I doubt there is a group of folks writing open source around the jdk 1.4 logging package. > However, we must also > distinguish between hype and reality. When log4j was won second place > in Javaworld 2001 annual awards, there was a lot of noise but not many > contributions. Contributions come in many flavors. They come in the > form of participation, as actual code or as ideas. In the course of > time we have established log4j as the de facto logging > framework. Ideas and contributions continue to flow in. We don't > always act on them immediately but that does not mean they are > lost. They will surface again in due course. I completely understand that contributions are not solely related to checking code into cvs. I value the group of folks on the user list that answer questions everyday. We need to find ways to empower the log4j user base to contibute in ways that "stick". It is too easy for email message to be posted and shunted to an email archive, maybe to be viewed again at a later date. Maybe wiki. Maybe sandbox cvs. > It is true that there was not much coding activity in the last two > months or so. My log4j book is very near completion. We are making > progress. However, we are doing so slowly, organically... I don't mind playing the tortoise as opposed to the hare. As you say, one of the greatest risks is that something half-baked will get into the package and then we'll be stuck with it or make people mad when we remove/change it. > Being a niche product, log4j cannot never attract hordes of > developers. Tomcat, JBoss can. Log4j cannot. Log4j does not cover an > area wide enough to keep everyone busy and interested. However, open > source still works in the case of log4j albeit differently. Developers > come up with a great idea, suggest it on log4j-dev, sometimes even > implement it and then leave, rarely to be heard of again. That's > cool. It is just not the fairy tale world of "The Cathedral and the > Bazaar". No! Actually it *is* the "The Cathedral and the Bazaar." In > the bazaar, things just don't go according to the original plan. :-) The example that disturbs me the most is the code that Mike McAngus submitted for timezone/locale support in pattern layout. He submitted patches, which we reviewed. He made changes based on those reviews and EVEN created test cases. Test cases! When was the last time any user submitted working patches with test cases? Make that person a committer! :-) But, for what ever reason, the task lost momentum. I feel that I have failed as a champion of those changes. I don't know if Mike is still around or not. I sent him an email after the v1.2 merge occurred, but never got a reply. Here was a guy that was dedicated to making a change to something that he (and others) perceived as needing fixing. Dedicated beyond the bounds we normally see. He probably got annoyed with the process/lack of support and walked away. Maybe he is still on this email list, waiting for one of us to say "ok, let's merge those patches". We can still apply his patches. I still have the code on my machine or it can be dug from the mail archives. But it disturbs me. What do we need to do differently to better support the Mike McAngus' of the world? Do we feel that this is an isolated case? If this happens often enough, don't we risk alienating the developers we are trying to serve? > Actually, I am extremely happy with the current state of affairs. Two > active comitters might be just the right size for a project like log4j. I wouldn't exactly call log4j a "niche" product, but it is fair to say that it is not going to get the attention and momentum of some other jakarta projects. I wouldn't expect it to. I don't agree, obviously, that 2 active committers is the "right size". Even commons-httpclient has (at least) 4 active committers and that is just as "niche" as log4j. I think that with more active committers we will be able to better support ideas, initiatives, and submissions from the user community to make log4j better. It will be healthier in the long run. But just making people committers won't work; the process must reward/recognize merit, effort, and interest. Anyway, I don't have much more to say on the topic. I see so much that can be done, and it doesn't all need to be done yesterday. I would feel more confident about it all if there were more hammers at the anvil. I'm still +1 for logging.apache.org, but we need to flesh it out. -Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
