RE: cvs commit: logging-log4j/src/java/org/apache/log4j LogManager.java

[Ceki Gülcü <ce...@qos.ch>]

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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org