At 07:51 PM 4/3/2007, Curt Arnold wrote:
There are still API incompatibilities
(http://people.apache.org/
~carnold/compatibility.html), particularly any user extensions of
DOMConfigurator (bug 39024) would not work with log4j 1.3.
LoggingEvent is not serialization compatible (bug 35159).
LoggingEvent.sequenceNumber can't achieve what it thought it could
achieve and should be removed (bug 36555, maybe others). The Gump
runs have been failing for over a year on the scheduler code behind
the reworked configureAndWatch methods. Mark Womack threw a quite a
bit of time on that and could not get it diagnosed. And if you
fixed all that, you would still break apps that didn't explicitly
call activateOptions(), it would not address the fundamental
concurrency problems and would still target early JDK's.
The problems you mention are really minor.
[snip]
I've been hesitant to deeply examine logback as its code is LGPL'd
and would want to avoid leakage of logback code into log4j. We have
a bit of a marketing disadvantage here as Ceki has been very vocal on
the mailing lists encouraging people to migrate to logback and saying
that log4j development is dead (I'd agree that it hasn't been healthy
recently, but we've never decided that it is dead). I'm also a bit
of a lightning rod for Ceki and think any evaluation of logback would
be better coming from someone else.
It's quite ironic that you should feel at "a
marketing disadvantage". While it is true that I
mention logback as a successor to log4j, I do so
occasionally. Moreover, I've extremely careful to
refer to log4j as "not actively developed", a
characterization, which as other log4j developers, you seem to agree with.
Do we really have plans to best it as Log4j-2.0? I'm not saying we
don't. I'm just asking the question.
logback is always going to be a better logback than log4j 2.0 and
likely a better log4j 1.3 than log4j 2.0. However, I think that the
design goals and approaches envisioned for log4j 2.0 will result in
something valuable to the community.
And what are we going to do about SLF4J? It's gained significant
acceptance and we've punted on how we are going to approach it;
implement it directly, write a wrapper for it (actually, this has
already been done by the SLF4J team), or ignore it altogether. So
far, we've chosen the latter as the path of least resistance.
From a packaging and maintenance perspective, it has always been
preferable that SLF4J be a wrapper over log4j. There were never any
benchmarks provided to quantify the supposed performance benefit of a
direct implementation. If I remember correctly, supporting SLF4J
directly introduced a breaking API change when code was recompiled.
I think the current state is the best for the community. log4j 1.2
users who want to use SLF4J can do so without forcing them to update
their log4j 1.2 version and log4j does not have a dependency on SLF4J.
The original version of UGLI and than SLF4J was
designed to be compatible with log4j.
[snip]
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
