Geir Magnusson Jr. wrote:
Well, the dependency issue is important, but not the only one. It certainly isn't a show stopper. Others are versioning, as you noted, and then also what this inflicts on users is another in terms of having to change how their applications' logging works.
1. Dependency issues... what do you think are reasonable guidelines to determine when to include code with velocity core? For example, the 1.3.1 velocity.jar includes anakia and texen, as well as some test cases, so there does seem to be a way to justify bundling with velocity (not counting velocity-dep).
Versioning is something we have no real solution for other than careful management of what we do - just a fact of Java life.
Yeah, though to your point, dependencies create the opportunity for versioning issues. Fortunately though, I can't say I've had much real-world problems with that as library authors (and the JDK) have been pretty good about limiting their changes.
Another one, is the lock-in to an API. Right now it's a nice API, but the moment that log4j does something we want to steal, support or can't live w/o, we have a problem, right?
This is an interesting point. So it's not necessarily that commons-logging is the LCD now, but it locks us into an LCD that can't grow.
The trade-off with this though is devoting extra effort to maintain that. Your comparing a dependency on log4j with c-l, when to be fair it should be compared with LogSystem. Granted you *can* LogSystem more easily, but it hasn't much.
I'll be the first to admit that we can improve LogSystem. I think we can do it to get the benefits people point out (like doing the isLEVELEnabled() to eliminate un-needed msg contruction, for example) w/o having to switch to c-l, especially if we can provide c-l support with an adapter, like we support everything else (and users support themselves).
Sure, although if you do a c-l adapter, you might as well make a log4j adapter too. :)
Well, if our impl is private, then we can, as time goes on, track whatever feature-set from whatever logger we want to. I'm assuming that it will be log4j, as the JDK moves with glacial speed and System.out.println() is a fairly complete API :). How will c-l track innovations in logging? I think it can't, because any feature that has no analogue in other loggers will not be able to be expressed in the c-l API, unless it has a set of log4j-specific methods, and then we're just using log4j anyway. This is sheer supposition - we have to wait and see.
Right, but a fair point.
Do you think Velocity has suffered though because there has been little or no inclusion of new logging features over the past 1-2 years? Not to suggest innovation happens at a consistent pace, but assessing the gap between modern logging libraries and LogSystem that has emerged over the past 1-2 years could suggest how much this will change in the future.
I realize that this sounds like a pro-log4j rant, but it isn't. It's just that log4j introduced the logging pattern that c-l uses, log4j was more or less copied (badly) for the JDK1.4 logger, and the System.out guy has retired from Sun :)
Seriously - I think that the log4j team will keep innovating, and I'd love to be able to take advantage of new things they invent.
Again - I'm still going to read c-l and give it a good think. There's nothing I would enjoy more than coming over to the dark side.
Here is my favorite pro-log4j/anti-c-l rant:
http://www.qos.ch/logging/thinkAgain.html
-- Serge Knystautas President Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
