On Sun, 2005-06-26 at 20:56 +0100, robert burrell donkin wrote: > i think that the next release should be a 1.1 release in any case. > however, i would prefer retaining Log4JLogger so that it can be properly > deprecated.
The problem is that people won't be referring to it in the normal way, via an import in their code (at least it's *theoretically* possible, but I can't imagine anyone actually subclassing Log4JLogger. The breakage is more when people refer to it in config files. Or possible call LogFactory.setAttribute(..., "org.apache.commons.logging.impl.Log4JLogger"); In neither case do we have any real mechanism for indicating deprecation to the user. We also need to consider that Log4J 1.3 is likely to be released within the lifetime of this release of commons-logging. If we provide a class called "Log4JLogger" that is not compatible with it, I'm concerned we will cause more pain than by simply removing that class. Remember that every person we would have "broken" by not including Log4JLogger would get broken anyway if they try to use Log4J 1.3, as Log4JLogger is not compatible with Log4J 1.3: we have a choice of breakage only: * message "Log4JLogger does not exist" (if we remove the class) * message "Log4JLogger cannot be initialised: log4j 1.2 not found" (if we include it) Given that we're going to break their apps either way (due to log4j's binary incompatibility) it seems sensible to do it right from the code point of view. Alternatively we could provide the Log4JLogger that is currently in SVN which is compatible with both log4j versions. But it is only compatible when we compile it against log4j1.3-alpha6 or later, and I'm really not keen on releasing a Log4JLogger class compiled like that. I'm wavering on the idea of releasing a Log4J13Logger compiled like that; depends how confident the log4j team are that they will stick with their API change plan. Currently, however, there seems to be confusion over when/if they are going to change the Category/Logger class hierarchy so I think there's still the possibility of further API changes from the log4j team in which case we should NOT include log4j1.3 support (ie Log4J13Logger) in the next release. Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
