Curt,
While I appreciate your efforts in resolving the Gump failure with the Hivemind tests, what we have currently works just fine and is quite simple to understand. Could we please move on?
At 08:03 PM 2/25/2005, Curt Arnold wrote:
Seems we have found ourselves in a revert war.
I really think we need to explain our positions and have a formal vote. My position is that we should not break compatibility with apps using or extending it in expected ways without discussion and if needed a formal vote. With the Gump breakage of Hivemind, I thought that I could proceed to restore 1.2 compatibility and then we could consider introducing potentially breaking changes.
I have the following problems with the commits from last week and the current CVS HEAD that I think were adequately addressed in the CVS HEAD from last night.
The new methods added to Appender will cause any independent implementation (not an extension of AppenderSkeleton) to fail to compile against 1.3. No such appender appears to exist within the projects built by Gump, but if the intent was to only allow instances of AppenderSkeleton to work with log4j, then addAppender should have taken AppenderSkeleton.
The new methods added to Appender are not essential aspects of an Appender and are not needed for an independent implementation to work with log4j. An independent implementation of Appender could throw NotImplementedExceptions on those methods and everything would work perfectly as they are not currently with log4j (they are called within test cases, but that can be handled other ways).
The new methods assumes a lifecycle of an appender being created in an inactive state, transitioning to active state and finally entering a closed state. Some appenders (VectorAppender, NullAppender) might never existing an in inactive state since they are immediately active on construction. Other appenders may have more complicated lifecycles, maybe entering a failure state or a dormant state where they drop database connections. The message dispatch logic has no need to know the internal state of an appender. If there develops an need to interrogate an appender about its internal state, then we should introduce distinct interfaces to support that and not just tack them on to Appender.
activateOptions on AppenderSkeleton was renamed to activate and implementations of activateOptions within the log4j code base were renamed. AppenderSkeleton.activateOptions was reimplemented to call activate. Existing custom appenders were expected to implement activateOptions and may have derived from an intermediate class like WriterAppender that now implements activate. This would result in a call to AppenderSkeleton.activate() and a call to AppenderSkeleton.activateOptions() since activateOptions would invoke the custom appenders activation code. If code wants to work properly with existing custom appenders, then it should call activateOptions since that is the only call that works correctly with both internal and existing custom appenders, but it is deprecated and the JavaHelp tells you to call the method that may be unsafe with existing custom appenders.
log4cxx (and likely) log4net attempt to mimic log4j's interfaces.
These changes require them to either propagate these changes with the similar effects on their users or freeze on the 1.2 versions of these interfaces. I've been trying to bring log4cxx into tighter alignment with log4j since that makes it easier to port log4j code into log4cxx and would prefer that we not have to branch.
-- 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]
