commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject Re: [logging] log4j 1.3 support
Date Sat, 01 Oct 2005 00:49:23 GMT
On Fri, 2005-09-30 at 13:30 +0200, Boris Unckel wrote:
> Hello,
> > > Level.Trace was introduced in 1.2.12
> > >
> >
> > You are right. Thanks!
> > And 1.2.12 is released. As soon as it is in the ibiblio, I will update the
> > version in project.xml
> > Only a little confusing that Log4J13Logger is for Log4j 1.2.12+
> > I will also add this as comment to the Log4J13Logger.
> Since these are internal classes I would recommend to detect the log4j
> Feature, not it's version, and rename the Log4J??Logger to
> feature dependend name (i.E. Log4JWithTraceLogger and Log4JLegacyLogger).
> The older one could be depraceted (first step/version) and afterwards
> made be final to make users who extended it, are forced to migrate
> in a definded timeframe.

Hi Boris/Joerg,

It's nice to see commons-logging getting some attention. Unfortunately I
don't have time to write a proper reply just now, but I will try to
address this tomorrow. Sorry I haven't joined the discussion earlier.

I did the Log4J12Logger/Log4J13Logger stuff, and the Trace support
currently in SVN.

Basically, Log4j 1.2 and log4j 1.3 are not binary compatible. There is
no way for us to write a single class that will run against both these
log4j versions. This is due to the way that the log4j team decided to
phase out the Category/Priority classes. This was discussed at length on
the log4j lists, and they were basically committed to that approach. So
we *must* have separate logger implementations for these two lib
versions. And we must compile each logger class against the appropriate
lib version, which basically makes using Maven to do the builds
impossible; Maven assumes one classpath is used to compile all the code.
So builds are ant-only.

Both the Log4j12Logger and Log4j13Logger classes *should* support the
Trace level if it exists. I thought I implemented this; if it isn't in
the trunk then maybe it is in one of the branches and I haven't merged
the changes into trunk yet.

Whether log4j12logger should be called Log4JLogger is debatable. There
are drawbacks to this. Yes, renaming the class will break setups where
someone has a config file that specifies Log4JLogger. However this setup
will fail anyway if they try to use log4j 1.3 in the classpath instead
of log4j 1.2. Given log4j's binary incompatibility between the two
versions we *can't* guarantee smooth upgrades for all combinations, and
I think the rename approach currently implemented will give the most
obvious error message, and have the most obvious fix for the users. This
is up for debate though.

[NB: I did the unit test changes too; I'll reply to the emails on that
topic tomorrow too].



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message