On Tue, 2005-06-28 at 22:32 +0100, robert burrell donkin wrote:
> > 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...
Agreed.
>
> > 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.)
The obvious solution is just to provide
/** @deprecated */
Log4JLogger extends Log4J12Logger {}
> > 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.
I don't believe "a lot of pain" is a fair assessment. They upgrade to
log4j 1.3, and run their app.
If they just use standard discovery then the new log4j 1.3 is
discovered, and all works fine.
If they use a commons-logging.properties file, a service file, or a
system property to specify Log4JLogger class then they get the message
Class not found: Log4JLogger does not exist
so they update the relevant config file and all works fine.
If they have code that does
LogFactory.setAttribute("o.a.c.l.i.Log4JLogger")
then they get the message
Class not found: Log4JLogger does not exist
and have to either update their code, or create a .java file containing
public class Log4JLogger extends Log4J12Logger {}
and drop the relevant .class file into their app.
The last is the only case that is at all awkward, and the fix still
takes less than 10 minutes and requires no immediate code changes
(though the original code should of course be updated sometime).
>
> > 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?
When a user uses a config file or call to setAttribute to specify
Log4JLogger as the adapter class:
* If we drop Log4JLogger from the jar we cause the problems
listed above.
* If we include a Log4JLogger that only works with Log4J 1.2
then when they put log4j 1.3 in their classpath their app
will also stop working. Ok, this is only triggered once they
upgrade to log4j1.3 rather than when they upgrade to JCL 1.1,
but it's going to happen eventually.
So we break such user code either way. What the user needs to do to fix
their app in either case is pretty similar. But the latter solution has
us shipping a junk class in JCL.
> > 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.
Agreed. I personally wouldn't even offer an optional jar; we can just
provide the source and let people compile it themselves as the fix is
just one class.
And obviously we can get ready when log4j 1.3 RCs start, so JCL can be
released on the same day.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
