We all agree that the discussion got unnecessarily heated. I also recognize that it would have been better to hold a discussion before proceeding with my additions to the Appender interface, rather than the other way around. The level of the reaction was well beyond what I had anticipated, especially considering that they seemed backward compatible, although later this assertion was shown to be inexact.
Presently, we are confronted with a situation where an appender in an erroneous state can behave erratically, for example by flooding the output of other appenders or entering endless loops.
As there are many appenders out there representing a relatively large body of code. They share common attributes but also have small differences. To verify that appenders function reasonably even under exceptional (erroneous) conditions, I started to write a battery of tests verifying this for each appender implementation. As you are probably aware, it is much easier to test code which reveals some information about internal state as opposed to completely opaque boxes. A little more transparency is the rationale behind the addition of the isActive(), isClosed() methods to the Appender interface.
I also added an internal check in AppenderSkeleton which short-circuited invoking appenders reportedly in an erroneous, i.e. inactive, state. This is the change that broke the Hivemind test which was subsequently caught by Gump.
Curt's changes preserve absolute backward compatibility. Although quite reasonable, they add an additional layer of complexity. Preserving backward compatibility is a very important goal. At the same time, it can eventually lead to over-convoluted and unmaintainable code. In my opinion, it is more economical to ask authors of appenders to make small updates to their code in order to adapt to changes in log4j 1.3. Note that we are talking about small, easily performed adaptations. I believe that trying to preserve *perfect* backward compatibility is beyond our resources.
To summarize, I think that log4j committers have to choose between:
1) For the sake of improvement, we allow for small changes, even in core interfaces, at the cost of perfect backward compatibility.
2) No, perfect backward compatibility is an overriding principle, more important than other considerations.
Comments?
-- Ceki G�lc�
The complete log4j manual: http://www.qos.ch/log4j/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
