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.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
