Curt,
I'd like to keep things simple and stupid. Imagining and implementing solutions for problems that do not exist makes the code hard to maintain. We already have a strategy for preserving backward compatibility which is both extremely simple and robust. More sophisticated solutions need to be maintained. They end up costing very dearly on the long run.
Please, let us keep things simple. Log4j is not about proving how smart we are but about providing a reliable solution for our users -- a solution which we can maintain on the long run.
At 12:23 AM 2/25/2005, Curt Arnold wrote:
I've committed some tweaks that I think should leave us in pretty good condition. I've modified the Gump descriptor for Cactus so that it should attempt to build against log4j 1.2 tonight which should allow us to tell if the recent breakage was due our recent changes.
I've restored the test of isActive in doAppend and the problematic statements in AbstractAppenderTest. To make these work, I've added explicit constructors for AppenderSkeleton. Code that uses the default AppenderSkeleton constructor will be created with active = true which should result in behavior consistent with 1.2 for custom appenders. If a custom appender did not require activateOptions to be called, it will still work and if it did require a call to activateOptions and none was made, it will still fail in the same manner. All log4j classes (with the exception of Chainsaw classes) that derive from AppenderSkeleton call AppenderSkeleton(boolean isActive) which indicates whether they are ready to process events immediately after construction. I didn't change the chainsaw appenders due to the recent migration and they should work consistently with their previous behavior. I did not intend to change the appenders in the contribution sections and will revert them later this evening.
In AbstractAppenderTest, I changed the type used in the tests from Appender to AppenderSkeleton. All the classes tested by AbstractAppenderTest are known to be inherited from AppenderSkeleton.
The message dispatching code does not currently need to know whether an appender is active or closed, it just calls append and assumes that the appender does something appropriate with its state. I don't see any need at this time to break any (possibly hypothetical) implementations of Appender that don't extend AppenderSkeleton.
I'm not sure about the duality of activate and activateOptions. It seems likely that there could be a problem when classes mix and match which methods they override. It may be better to change the implementations back to activateOptions and provide a final activate method that delegates to activateOptions. However, I did not work through the permutations.
-- 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]
