Hi, A few things. First of all, thanks for everyone for expressing their opinions, but remember that in ASF votes for a given module only committer votes are binding (for logging-logj, that's ceki,mwomack,hoju,psmith,sdeboy,yoavs @ apache.org), so don't be surprised if your vote isn't counted in the final tally.
(Quoting is intermixed from various messages in this thread) >If users want a feature which log4j can give them nearly >for free, why not do it? Even if it may not be the optimal >approach to logging. There's a general answer to that, which goes to the tune of scope creep and against the KISS principle. Much like it'd be a trivial extension for Sun to add some commons-lang-type utilities to the JDK, but they don't do it: make a simple and easily extensible core, and let users extend as they wish, which log4j has done since its beginning. >3. The issue isn't about domains or other levels. Even when domains > are in the stable release, many may choose to stick with simply > using levels. I agree with that. >* To give an idea of how I think the levels should be used, This is >how I have extended the Level class. I have added the following levels: > > CONFIG: Configuration information- system/app specific properties, >details of connections made (CORBA domains, databases, JMS) > PERF: Performance metrics- our wrapper prepends "perf." to the >category to allow any performance stats to be handled via a specific >appender. <snip, though poster goes on with INFO_LOW, INFO_MED, INFO_HIGH, and a wrapper to map things around /> The point is that you could extend this class to meet your needs easily. I also agree with Elias' point that you could use a PERF logger and a CONFIG logger rather than a custom level for those, but that's not the main point. So this is a good example of a very specific use-case that you have, which wasn't raised that much even among TRACE proponents (the majority of which think DEBUG/TRACE is good but FINE/FINER/FINEST is not). >Personally, I think the TRACE feature is dubious at best. If it was me >writing for myself, I'd say -1, but if it makes the user base happy and >if log4j is truly user-driven, then let's do it. It's not going to do >much harm for the rest of us who don't need it. (But I would have to >draw the line at adding FINE, FINER, FINEST as well.) I feel much the same way. >if(log.isTraceEnabled()) log.trace(<probably very expensive string >creation>) >which is less obscuring in the code. After all we are talking about the >trace-level, the finest grained default level, which means that there >will be lots of lines like the above in the source! This is one of the >main reason why it should be included. Readable code is important. Readability and performance are sometimes at odds. Your example would have negligible difference IMHO, but then again readability (unlike performance) is subjective. >However, isn't there a potential problem with the fact that many servers >include logj4 in the classpath by default? It's safe to assume relevant components, including commons-logging, JBoss logging, and others, will need at least a new point release to accommodate support/integration with log4j 1.3. That's also our viewpoint on commons-dev with regards to commons-logging 1.1. So to summarize my views: - TRACE is useless to me, but useful to a number of users, - Domains are an orthogonal approach, not a replacement for levels, - Log4j is community owned, and maintaining that in letter as well as spirit (or perception as someone called it earlier) is more important than pretty much all the technical arguments e.g. code bloat and backwards compatibility. >> [ ] +1, Yes, the TRACE would be a useful addition >> [ X ] 0, I don't care >> [ ] -1, No, TRACE should not be included Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
