To help wrap this up, would you mind providing a little history into the conversations that took place when LocationInfo was first added?
I assume the same issue was discussed - LocationInfo's lack of reliability versus its benefit to the end user. That conversation must have tipped in favor of benefit to the end user. It would seem that someone arguing for this change could (but I won't) use the same argument in support. I'm just trying to get clarification so we don't run into similar misunderstandings in the future. Scott -----Original Message----- From: Ceki Gülcü [mailto:[EMAIL PROTECTED] Sent: Mon 12/20/2004 10:21 AM To: Log4J Developers List Cc: Subject: RE: cvs commit: logging-log4j/src/java/org/apache/log4j LogManager.java 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]
<<winmail.dat>>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
