Hello,
Indeed, testing the automatic logger naming feature will be quite hard to test on all platforms. Not only that, the behavior of a particular JVM may vary between the test environment and the environment of a real-world application. So no amount of brute-force (automated) testing will uncover all potential problems. The introduction of this feature requires the careful study of JVM implementations by looking at their source code and retaining the automatic logger naming feature only in the case of safe JVM implementations. However, that would mean that log4j would not run properly on some "non-compatible" implementations. Unless we accept that log4j will not run on "unsafe" JVMs, which can be all of them btw, this feature cannot be allowed in.
Logging is for diagnosing problems. As a logging API, log4j must be very reliable. It cannot be the source of doubts or trouble. As log4j developers, we do not have the luxury of knowingly introducing unreliable features and then hope for the best. We have to be very conservative in what we do but at the same time be very flexible in what we accept from our users.
Silly bugs get fixed quickly. You can laugh at these looking them straight in the eye. It is the hard-to-detect, hard-to-reproduce bugs that must be feared; they take eons to get rid of. One of the reasons I'm so appalled by JCL can be traced back to this principle. It was rather obvious that a classloader based discovery mechanism would cause terrible headaches for countless people. Unfortunately, reliably was sacrificed at the altar of a nice-to-have feature.
I am not saying that every line of log4j must be scrutinized as much as the code that goes into the Space Shuttle. Log4j surely has bugs but hopefully not at its core, at least not of the hard-to-detect hard-to-reproduce kind.
At 04:17 PM 12/20/2004, Scott Deboy wrote:
I don't think we (dev) have the resources ourselves to perform this testing, since testing this chane necessarily requires a wide variety of JVMs. It sounds like we have a bit of a chicken and egg problem here.
I made the change for these reasons: - No existing code relies on this change - It's not required - folks can still use logmanager.getlogger(classname) - It reuses existing (LocationInfo) code for class name discovery - It's a (very) convenient feature - We're in an alpha
The last one may be controversial, but I feel we have to rely on the variety of configurations out there to verify the change works - if it doesn't work in some cases, we pull it or document it. But we should (at some point) at least try to provide this feature, obviously documenting it's possible limitations.
I'm not arguing for a re-add, I'm just explaining why I made the commit.
-- Ceki G�lc�
The complete log4j manual: http://qos.ch/log4j/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
