On Mon, 2005-06-27 at 11:22 +1200, Simon Kitching wrote: > 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.
IMHO we should have marked them all final to exclude this possibility. JCL is one of the cases when creating a new implementation based on the source of another is better... > The breakage is more when people refer to it in config files. Or > possible call > LogFactory.setAttribute(..., > "org.apache.commons.logging.impl.Log4JLogger"); that's the point: i was wondering whether we could preserve compatibility by having some mechanism that guesses which implementation to use. (we'll need something like this to support dynamic binding.) > In neither case do we have any real mechanism for indicating deprecation > to the user. we still have the old form of deprecation: the release notes :) > 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) by removing support for log4jlogger, we break support for existing deployments: it's no longer a drop in replacement. anyone upgrading to the new log4j version is going to expect a lot of pain including having to upgrade. > 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. i'm not sure i parse this correctly. could you expand? > 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. i think that we need to work on log4j support and think about the right way to make this change. however, until there is a full release it would be wrong to include support within the core jar. i wouldn't object to support within an optional jar or ask those requiring support to use the source release. we could then release a new version once a full log4j 1.3 release is available. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
